让你设计一张每天新增千万数据的订单明细表，你会怎么定字段、主键、索引和归档策略？
我的判断
日增千万订单明细要从查询、写入和生命周期反推字段与索引；主键、唯一约束、在线索引和归档策略要一起设计。
我会先列出 Top 查询：用户查订单、商家按状态处理、按订单号点查、财务按时间导出。字段使用明确类型，金额存整数分，状态用小整数，时间用毫秒精度；大文本和低频扩展信息拆到详情表，避免主表过宽。
主键选择趋势递增的全局 ID，减少随机写导致的页分裂；业务订单号另建唯一约束。索引只围绕真实访问路径，例如：
PRIMARY KEY (id),
UNIQUE KEY uk_tenant_order_no (tenant_id, order_no),
KEY idx_user_time (tenant_id, user_id, created_at, id),
KEY idx_status_time (tenant_id, status, created_at, id)
日增千万意味着一年数十亿，建表当天就要定义在线保留期。比如主库保留 3~6 个月，按主键/时间小批归档到历史库或分析系统，校验数量和摘要后再删除，整个过程控制 Undo、binlog 和复制延迟。
分区可以帮助生命周期管理，但不会自动让坏 SQL 变快。只有单实例在容量、备份恢复或写吞吐上接近上限，才进入分库分表设计。
思路拆解问题分析
表设计不是字段清单。需要同时回答：最常用查询怎样定位、每次写入要维护多少索引、历史数据何时离开在线库、唯一性由谁保证。 日增量只是让错误设计更快暴露。