子查询性能差因外层条件无法下推导致全表扫描，应改写为JOIN、建覆盖索引、用EXISTS替代IN、避免相关子查询逐行执行。
子查询被当成“黑盒”，索引根本没生效
MySQL 和 PostgreSQL 都可能把子查询当作独立执行单元，外层 WHERE 条件无法下推，导致内层全表扫描。尤其当子查询带 ORDER BY 或 LIMIT 时，优化器常放弃合并执行计划。
实操建议：
- 用
EXPLAIN看子查询是否出现在select_type=DEPENDENT SUBQUERY或更糟的UNCACHEABLE SUBQUERY—— 这意味着每次外层行都要重跑一遍 - 优先改写为
JOIN：把WHERE id IN (SELECT user_id FROM logs WHERE status = 'error')换成INNER JOIN logs ON t.id = logs.user_id AND logs.status = 'error' - 如果必须用子查询，确保子查询里涉及的字段（如
user_id、status）有联合索引，且顺序匹配过滤条件
覆盖索引没覆盖全，还是得回表查数据
以为加了索引就万事大吉，但子查询里 SELECT * 或未包含所有需要字段，会导致索引扫描后仍要回主键索引取数据，IO 翻倍。
实操建议：
- 子查询只
SELECT外层真正需要的列，比如外层只要user_id，就别在子查询里SELECT * - 对子查询涉及的表建覆盖索引：例如子查询是
SELECT user_id FROM logs WHERE app = 'web' AND created_at > '2024-01-01'，索引应为INDEX(app, created_at, user_id)—— 把WHERE字段放前面，SELECT字段放最后 - PostgreSQL 注意：
INCLUDE列不参与查找，只用于覆盖，别把它当过滤字段用
相关子查询（correlated subquery）性能雪崩
WHERE x = (SELECT y FROM t2 WHERE t2.id = t1.ref_id) 这类写法，每行外层数据都触发一次内层查询，10 万行外层 = 10 万次独立执行，哪怕内层走索引也扛不住。
实操建议：
- 立刻转成
LEFT JOIN+GROUP BY或窗口函数：用MAX(t2.y)替代标量子查询，避免逐行调用 - 如果业务逻辑真依赖“每行单独算”，确认内层表是否有高效索引支撑
t2.id = t1.ref_id，且t2行数远小于t1 - MySQL 8.0+ 可尝试用
LATERAL（需开启），但实际效果取决于数据分布，别盲目信文档说的“自动优化”
IN 子查询结果集过大，触发临时表或内存溢出
当 IN (SELECT ...) 返回几万甚至几十万 ID，MySQL 可能放弃哈希查找，降级为 NESTED LOOP；PostgreSQL 则可能把子查询结果物化成临时表，磁盘 IO 暴增。
实操建议：
- 用
EXISTS替代IN：语义等价但优化器更容易利用索引，特别是子查询结果集大时 - 限制子查询返回量：加
LIMIT 1（仅适用于判断存在性）或提前用WHERE过滤掉无效范围 - 如果必须传大批量 ID，考虑分批处理：比如每 500 个一组，用
IN (1,2,...,500)多次执行，比单次传 5 万个更稳
最常被忽略的一点：子查询性能问题往往不是语法本身的问题，而是它把原本可以走索引合并的逻辑，硬生生切成了两段独立执行流。优化的第一步，永远是看 EXPLAIN 里有没有出现 DEPENDENT SUBQUERY 或 Using temporary; Using filesort —— 这些才是真实瓶颈信号。
