子查询归档易卡死因默认不去重、不控范围、不压平主键；应分两步：先物化收敛ID到临时表，再关联查完整记录。
子查询在归档场景下极易放大行数、拖慢执行、甚至触发锁表或OOM——根本原因不是语法错，而是它默认不做去重、不控范围、不压平逻辑主键。
为什么归档时用子查询容易卡死或报错
历史归档常需“找出要归档的订单ID，再查完整记录”，但直接写 SELECT * FROM orders WHERE id IN (SELECT id FROM orders WHERE status = 'closed' AND create_time 会出问题：
- 子查询若未加
DISTINCT或GROUP BY，可能返回重复id，外层查询自动去重但代价是临时表膨胀 - MySQL 8.0+ 对
IN (subquery)的优化有限，尤其子查询含JOIN或聚合时，常退化为循环嵌套（N×M） - 子查询未限定分区或时间范围，易触发全表扫描，归档任务一跑就是几小时，还占满 buffer pool
- Oracle 中类似写法配合
MERGE更危险：ORA-30926就是因为子查询输出不稳定，导致ON匹配抖动
用 EXISTS 替代 IN 是最简见效的改法
EXISTS 不生成中间结果集，只做布尔判断，对大表更友好。关键是要把子查询写成“半连接”语义，且确保关联字段有索引：
SELECT o.*
FROM orders o
WHERE EXISTS (
SELECT 1
FROM order_status_log l
WHERE l.order_id = o.id
AND l.status = 'closed'
AND l.update_time < '2024-01-01'
);- 必须确保
order_status_log.order_id有索引，否则EXISTS内部仍是全表扫 - 避免在子查询里用
SELECT *或聚合函数，SELECT 1足够 - 如果
order_status_log是分区表（如按月），务必在子查询中显式加AND l.dt >= '202312'，防止优化器忽略分区裁剪
归档前先物化中间结果到临时表
当逻辑复杂（比如要取每个订单最新一条归档快照），硬塞进子查询只会让优化器放弃挣扎。不如分两步：先收敛，再关联。
-- 第一步：安全压平源数据
CREATE TEMPORARY TABLE tmp_archive_ids AS
SELECT order_id
FROM (
SELECT order_id,
ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY update_time DESC) rn
FROM archive_log
WHERE dt >= '202312' AND dt <= '202401'
) t
WHERE rn = 1;
<p>-- 第二步：用临时表驱动主表
INSERT INTO archive_db.orders
SELECT o.*
FROM orders o
INNER JOIN tmp_archive_ids t ON o.id = t.order_id;- 临时表自带隐式索引（内存引擎下），
JOIN效率远高于子查询 -
ROW_NUMBER()必须出现在子查询里，不能丢到外层——否则无法保证“每 order_id 只取一行” - 别省略
WHERE dt条件：归档表若按月分区，漏掉这个等于扫全表
千万别在子查询里写业务聚合逻辑
比如“归档过去一年已结算且退款率 GROUP BY merchant_id 算退款率。这会导致：
- 子查询输出行数远小于原表，但聚合过程消耗大量 CPU 和 sort_buffer
- 外层
IN或JOIN时，数据库可能放弃使用索引，改走 hash join 或 nested loop - 一旦退款率计算涉及多表
JOIN，行数会被笛卡尔放大，归档任务直接 OOM
正确做法是：先把符合条件的 merchant_id 单独拎出来建临时表，加索引，再和订单表 JOIN。归档不是拼 SQL 行数少，是拼执行路径稳。
真正麻烦的从来不是语法怎么写，而是你有没有在跑之前，先用 EXPLAIN 看一眼子查询的 rows 和 type——如果显示 ALL 或预估行数超百万，别犹豫，立刻拆。
