关联子查询慢是因为每次外层行都触发内层重算，临时表是唯一能真正打断该循环的手段；需显式建表、建索引并清理，且注意驱动表选择与索引使用。
关联子查询慢，不是因为写法不对，而是每次外层行都触发一次内层重算——临时表是唯一能真正打断这个循环的手段。
为什么关联子查询（DEPENDENT SUBQUERY）总被反复执行
数据库不会把 SELECT * FROM orders o WHERE o.user_id IN (SELECT id FROM users WHERE region = 'CN') 里的子查询结果缓存起来。只要外层 orders 表扫描到一行，就重新跑一遍子查询——哪怕 users 表没变、条件没变、结果集完全一样。
- EXPLAIN 中看到
select_type = DEPENDENT SUBQUERY且rows值很大，基本就是它在拖慢整条语句 - MySQL 8.0+、PostgreSQL 12+、SQL Server 都不保证物化，CTE 在这里只是语法分组，不是缓存指令
- 聚合、
GROUP BY、LIMIT会直接让优化器放弃内联，强制走临时表路径，但那是它自己建的隐式临时表，你控制不了索引和生命周期
什么时候必须用临时表替代关联子查询
满足以下任一条件，就该立刻停手嵌套，改用显式临时表：
- 子查询返回结果 > 10k 行，且主查询要对它做
JOIN或多次EXISTS判断 - 同一子查询逻辑在多个地方复用（比如既用于
WHERE又用于SELECT子句） - 子查询含
MAX(created_at)、COUNT(*)、ROW_NUMBER()等无法下推的计算 - 你发现执行计划里出现
Using temporary; Using filesort节点落在子查询上
建临时表三步不能省：结构、索引、清理
只写 CREATE TEMPORARY TABLE tmp AS SELECT ... 是最常见踩坑起点。真正起效靠后面两步：
- 字段类型必须显式定义或验证：避免
SELECT *导致INT被自动转成BIGINT，后续JOIN失去索引优势 - 对所有参与
JOIN、WHERE、ORDER BY的列，立即建索引：CREATE INDEX idx_user_id ON tmp_orders (user_id) - 存储过程中务必加
DROP TEMPORARY TABLE IF EXISTS tmp_orders开头——连接池复用时，残留临时表会导致Table 'tmp_orders' already exists报错
临时表对接主查询的关键细节
临时表建好了，不代表性能就上来。真正卡点在怎么连、怎么查：
- 驱动表要小：确保主查询中作为
JOIN左侧的表（如users）行数可控（几千以内），否则优化器可能选错执行顺序 - 别在临时表字段上套函数：
WHERE DATE(last_time) = '2026-05-24'会让索引失效，改用WHERE last_time >= '2026-05-24' AND last_time - 仅需存在性判断时，用
EXISTS (SELECT 1 FROM tmp_orders WHERE user_id = u.id)，比IN (SELECT user_id FROM tmp_orders)更稳，也更易走索引
临时表不是“多建一张表”那么简单，它是把隐式、不可控的中间计算，变成显式、可索引、可调试的物理存在。最容易被忽略的是索引那一步——没索引的临时表，和没优化的子查询，性能差距往往不如预期。
