直接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 对着看，而不是等它跑完再查日志。