直接JOIN千万级订单表和明细表会卡死，因缺乏索引和过滤条件导致全表扫描、嵌套循环匹配量达数十亿次，并触发磁盘临时表与内存爆满；必须加时间/状态前置条件、确保order_id等关联字段有索引、分区裁剪及归档后ANALYZE表。
为什么直接 JOIN 千万级订单表和明细表会卡死？
因为数据库执行 JOIN 时，若缺乏有效过滤和索引支撑，很容易触发全表扫描 + 哈希连接（或嵌套循环），内存爆满、磁盘临时表撑爆、查询跑十几分钟甚至超时。尤其当订单表有 2000 万行、明细表有 1.2 亿行，且没有业务时间范围约束时，EXPLAIN 往往显示 type: ALL 和 rows 接近总行数。
关键不是“能不能 JOIN”，而是“在什么条件下 JOIN 才可控”。真实归档场景里，你几乎从不查全量——通常只归档「过去 3 个月已关闭的订单」及其明细。必须把时间、状态、分区键作为硬性前置条件。
- 强制加
WHERE order_status = 'closed' AND order_time >= '2024-07-01'，且该字段组合必须有复合索引 - 如果表按月分区（如
PARTITION BY RANGE (TO_DAYS(order_time))），确保WHERE条件能精准裁剪到 1–3 个分区，避免扫描全部 - 避免在
JOIN条件里对字段做函数操作，例如ON DATE(o.order_time) = DATE(d.create_time)会让索引失效
用 INSERT ... SELECT 分批归档比 CREATE TABLE AS SELECT 更安全
CREATE TABLE AS SELECT 是原子操作：它会先锁住所有被读取的源表页，构建完整结果集再落盘，期间阻塞写入、占用大量 undo/redo 日志。而归档是后台任务，不能影响线上订单写入。
更稳妥的做法是分批次 INSERT ... SELECT，每次只处理几千到一万行，并配合显式事务控制：
INSERT INTO archive_order_detail (order_id, sku_id, qty, price) SELECT o.id, d.sku_id, d.qty, d.price FROM order_202407 o INNER JOIN order_detail_202407 d ON o.id = d.order_id WHERE o.status = 'closed' AND o.id BETWEEN 1000000 AND 1009999;
- 主键或自增
id是最稳定的分片依据，比order_time更不易重复或遗漏 - 每次处理区间宽度建议 ≤ 10000，太大容易超时；太小则网络和事务开销占比过高
- 务必在
order_202407和order_detail_202407上都有(status, id)和(order_id)索引
明细表没建 order_id 索引？立刻补，别信“以后再优化”
这是千万级归档中最常被忽略的致命点：订单表有主键 id，但明细表只有自增主键 id，order_id 字段完全没索引。此时 JOIN 会强制对明细表全表扫描——1.2 亿行 × 每次归档 5000 订单 = 600 亿行匹配尝试。
验证方式很简单，在从库执行：EXPLAIN SELECT * FROM order_detail WHERE order_id = 123456; 如果 key 列为 NULL，就确认缺失。
- 加索引命令：
ALTER TABLE order_detail ADD INDEX idx_order_id (order_id); - 如果表太大（>50GB），用
pt-online-schema-change或 MySQL 8.0+ 的ALGORITHM=INPLACE避免锁表 - 注意：不要建
UNIQUE索引，明细天然一对多，重复order_id合理
归档后记得 ANALYZE TABLE，否则优化器可能继续走错路
MySQL 的统计信息不会自动实时更新，尤其是大批量 INSERT 或 DELETE 后。如果你刚把 800 万行从 order_202407 归档走，接着查剩余数据，优化器仍可能基于旧的行数估算选择嵌套循环而非索引合并，导致下一次抽取又变慢。
归档脚本最后加一句：
ANALYZE TABLE order_202407, order_detail_202407;
- 这步耗时很短（毫秒级），但能强制刷新
cardinality，让后续JOIN计划回归理性 - 某些运维平台会禁用
ANALYZE，需提前确认权限；若不可用，至少手动SELECT COUNT(*)触发一次采样 - 别依赖
innodb_stats_auto_update，它只在变更量 > 10% 时触发，而归档往往是 90% 清空，反而错过时机
真正卡住归档的，往往不是语法或算力，而是索引缺失、条件松散、统计失真这三处静默错误。每一步都得拿 EXPLAIN 对着看，而不是等它跑完再查日志。
