先看执行计划定位瓶颈：MySQL用EXPLAIN、PostgreSQL用EXPLAIN ANALYZE，重点查DEPENDENT SUBQUERY、Actual Total Time占比超60%、rows预估严重偏差三处；再依场景选JOIN/CTE/临时表优化。
多层嵌套查询慢，八成不是“嵌套”本身的问题，而是子查询反复执行、没走索引、或优化器干脆放弃了精确估算。别急着重写，先看执行计划里哪一层在拖后腿。
怎么看嵌套哪一层真拖慢了？
直接跑 EXPLAIN ANALYZE（PostgreSQL）或 EXPLAIN（MySQL），重点盯三处：
-
type出现DEPENDENT SUBQUERY：说明外层每行都触发一次子查询，10 万行 = 10 万次执行 - 子查询节点的
Actual Total Time占整条语句超 60%，但Rows很小（比如只返回 5 行）→ 典型相关子查询未物化 -
rows预估数远大于实际（如预估扫 200 万行，实际只留 12 行）→ 缺索引或条件没下推
IN 子查询该不该换 EXISTS？
不是所有 IN 都该换，盲目替换可能更慢甚至逻辑错。只在满足这三条时才值得动：
- 子查询能走索引（比如
WHERE c.id = o.customer_id AND c.status = 'active'，且(status, id)有联合索引） - 你只关心“是否存在”，不依赖子查询返回的具体值（
EXISTS完全忽略SELECT列） - 子查询结果集较大（占主表行数 >10%），且主表相对小；反之若子查询只返回几十行，
IN可能被优化器转成哈希查找，更快
安全改写必须做三件事：SELECT * 改成 SELECT 1；补上关联条件（否则变笛卡尔积）；遇到 GROUP BY 或 LIMIT 就别硬套，得保留子查询或改用 JOIN。
什么时候该拆成临时表或 CTE？
当子查询逻辑复杂、被外层多次引用、或需提前过滤大结果集时，硬嵌套会让优化器失控。此时显式中间结构更可控：
- MySQL 8.0+ / PostgreSQL：优先用
WITH（CTE），但注意老版本 MySQL 5.7 不支持视图合并，WHERE加在 CTE 外层可能白加 - 需要复用多次或子查询含聚合：建
TEMPORARY TABLE，并立刻给关键字段加索引（如CREATE INDEX idx_user_id ON tmp_orders(user_id)） - CTE 被“内联展开”导致重复执行？MySQL 8.0.23+ 可加
MATERIALIZED提示，PostgreSQL 用/*+ MATERIALIZE */
分页和“最新 N 条”类嵌套怎么破？
这类最易失控，因为 LIMIT 常被挂在外层，导致数据库先算出全部再截断：
- 别在最外层才
LIMIT：先用子查询或 CTE 拿到目标user_id列表，再用IN或JOIN查明细 - 找“每个用户最新 3 笔订单”？用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)，比自连接 +ORDER BY ... LIMIT 3高效得多 - 深度分页（如
LIMIT 100000, 10）？改游标分页：WHERE id > last_seen_id ORDER BY id LIMIT 10
真正容易被忽略的是 NULL 传播和空关联场景——拆分后必须用全字段哈希比对结果，尤其验证子查询返回空或含 NULL 时，外层逻辑是否仍正确。
