dependent subquery是性能瓶颈主因，因主表每行都重复执行子查询；应改用left join或exists替代，并确保条件正确下推、索引有效、避免隐式转换。
看执行计划里有没有“DEPENDENT SUBQUERY”或“MATERIALIZED”
真正拖慢查询的，往往不是子查询本身，而是优化器把它识别为「相关子查询」——也就是每扫主表一行，就重跑一次子查询。MySQL 的 EXPLAIN 里一旦出现 DEPENDENT SUBQUERY，基本可以判定是冗余嵌套的典型信号；PostgreSQL 则可能显示 MATERIALIZED + 多次 Seq Scan。这不是预估问题，是真实执行路径。
常见诱因包括：
- WHERE 中用了
IN (SELECT ... FROM t2 WHERE t2.x = t1.y)，且t2.x没索引 - 子查询里引用了外层表字段，但没走 JOIN 条件推导（比如写成
t2.x = t1.y + 0，隐式类型转换或计算导致无法下推） - 子查询返回字段含
SELECT *或未加LIMIT 1，让优化器不敢做物化优化
用 EXPLAIN ANALYZE 看实际扫描行数是否爆炸
别信 EXPLAIN 里预估的 100 行——EXPLAIN ANALYZE（PostgreSQL）或 EXPLAIN FORMAT=JSON + 查 information_schema.PROFILING（MySQL）才能看到真实行为。如果子查询部分显示「实际扫描 12 万行，预估仅 800 行」，说明统计信息过期或条件选择率严重误判，嵌套结构放大了误差。
这时要做的不是调优子查询，而是先拆掉嵌套：
- 把
WHERE id IN (SELECT id FROM t2 WHERE status = 'active')改成INNER JOIN t2 ON t1.id = t2.id AND t2.status = 'active' - 若子查询只用来判断存在性，一律换
EXISTS，它能在找到第一行就短路，不加载全部结果 - 避免在子查询的
ON或WHERE里写函数，比如UPPER(t2.name) = UPPER(t1.name)，索引直接失效，必然触发全表扫描
检查是否用错 CTE 或视图包装了无意义嵌套
CTE 不是性能优化语法糖，而是逻辑分组工具。很多人把 WITH t AS (SELECT * FROM ...) SELECT * FROM t WHERE ... 当成“简化”，其实只是把嵌套从内层移到了外层，执行计划完全没变。更危险的是 SQL Server 中误用 CTE 驱动多表 DELETE，语法报错后硬改成 DELETE FROM t1 WHERE id IN (SELECT id FROM cte)，CTE 内部又套了一层子查询——等于嵌套 ×2。
识别方法很简单：把 CTE 展开，和原始语句比对执行计划。如果 EXPLAIN 结果一致，那这个 CTE 就是纯装饰。
- 真正有效的 CTE 是能复用中间结果的，比如
WITH ranked AS (SELECT ..., ROW_NUMBER() OVER (...))后面多次引用ranked - 视图里藏子查询更要警惕，MySQL 视图默认是
TEMPTABLE算法，每次查都重建临时表，比原生子查询还重 - 用
SHOW CREATE VIEW view_name把视图定义捞出来，手动展开一层，再EXPLAIN对比
当心窗口函数被当成“嵌套替代方案”滥用
有人听说窗口函数能替代子查询，就一股脑把 MAX() OVER ()、COUNT(*) OVER () 塞进语句，结果发现比原来还慢。这是因为空 OVER () 在 PostgreSQL 中强制全局排序，MySQL 8.0+ 虽支持，但若没配 sort_buffer_size，照样溢出到磁盘排序。
关键判断点：
- 你真需要“每行都带总数”？还是只需要一个
SELECT COUNT(*)先查出来，再用应用层拼接？后者更可控 -
ROW_NUMBER() OVER (PARTITION BY x ORDER BY y)必须显式写ORDER BY，否则编号顺序不可靠，业务上可能误删/误选 - 多个不同
PARTITION BY的窗口函数共存时，PostgreSQL 会分别排序，千万级表下耗时翻倍很常见
嵌套子查询是否冗余，最终得看它有没有引入额外扫描、排序或临时表——而不是看代码缩进有几层。最隐蔽的冗余，往往藏在看似“结构清晰”的 CTE 和窗口函数里。
