子查询嵌套过深会导致mysql/postgresql优化器放弃外层索引而全表扫描，应优先用join改写相关子查询，并注意null处理、驱动表顺序、索引覆盖及lateral（pg）或窗口函数（mysql 8.0+）等语义保持手段。
子查询嵌套太深导致执行计划走不了索引
MySQL 或 PostgreSQL 遇到多层 WHERE ... IN (SELECT ...) 或 WHERE col = (SELECT ...) 时，优化器常放弃使用外层索引，转而全表扫描。这不是语法错，是执行路径被“吓退”了——子查询结果集不可预估，优化器不敢赌。
- 先用
EXPLAIN看执行计划，重点盯type列：出现ALL或index（非ref/eq_ref）基本就是子查询拖了后腿 - 把相关子查询（correlated subquery）改写成
JOIN，让优化器能一次性估算驱动表和被驱动表的行数 - 注意
NULL处理差异：子查询返回空结果等价于FALSE，而LEFT JOIN ... IS NULL才等价于NOT EXISTS - 如果原语句有
GROUP BY或聚合函数，改写后需确认JOIN是否引入重复行——可能得加DISTINCT或调整ON条件
JOIN 改写时 ON 条件漏掉关键过滤字段
把 WHERE 里的条件直接挪进 JOIN ... ON 是常见操作，但容易忽略“过滤时机”差异：放在 ON 是连接时过滤，放 WHERE 是连接后过滤。对 LEFT JOIN 尤其致命。
-
LEFT JOIN t2 ON t1.id = t2.t1_id AND t2.status = 'active'→t2只匹配活跃记录，t1行仍保留 -
LEFT JOIN t2 ON t1.id = t2.t1_id WHERE t2.status = 'active'→ 实际变成INNER JOIN，t2为空的t1行被干掉 - 检查原子查询逻辑是否隐含“必须存在”的语义（如
EXISTS），对应改写应优先用INNER JOIN；若允许缺失（如NOT EXISTS），才考虑LEFT JOIN ... IS NULL
改写后性能反而更差？检查驱动表顺序和索引覆盖
JOIN 不是万能加速器，选错驱动表或缺索引，可能比原查询还慢。数据库通常按 FROM 后第一个表作为驱动表（MySQL 5.7+ 会尝试重排，但不保证最优）。
- 确保
JOIN条件字段在两张表上都有索引，特别是被驱动表的ON字段——比如t2.t1_id必须有索引，否则每次匹配都要扫全表 - 用
EXPLAIN对比rows和filtered：如果驱动表预估行数远大于子查询原本的“小结果集”，说明改写没占到便宜 - 把原
SELECT中只用到的字段列出来，给被驱动表建联合索引（如(t1_id, name, created_at)），避免回表
PostgreSQL 中 LATERAL JOIN 比普通 JOIN 更贴近原意
当子查询依赖外层字段且本身较复杂（比如带 LIMIT、ORDER BY、窗口函数），硬套普通 JOIN 会丢失语义。PostgreSQL 的 LATERAL 允许子查询“按行求值”，更安全。
- 原写法：
SELECT t1.*, (SELECT name FROM t2 WHERE t2.t1_id = t1.id ORDER BY score DESC LIMIT 1) AS top_name - 改写为：
SELECT t1.*, t2.name FROM t1 LEFT JOIN LATERAL (SELECT name FROM t2 WHERE t2.t1_id = t1.id ORDER BY score DESC LIMIT 1) AS t2 ON true - MySQL 8.0+ 无
LATERAL，只能用派生表 +ROW_NUMBER()模拟，但要注意PARTITION BY字段必须和关联条件一致，否则分组错乱
ORDER BY 或 LIMIT，往往决定了你该用 LATERAL、窗口函数，还是老老实实保留子查询。
