用join替代三层以上相关子查询可显著提升性能，因postgresql对相关子查询仅支持嵌套循环，而join可利用hash或merge等高效算法；需配合覆盖索引、下推过滤条件及explain analyze验证。
用 JOIN 替代三层以上相关子查询
PostgreSQL 对相关标量子查询（比如 SELECT a.id, (SELECT b.name FROM b WHERE b.a_id = a.id)）只能走嵌套循环，表 a 每扫一行就触发一次子查询执行——若 a 有 10 万行，实际就是 10 万次独立查询。这和等价的 INNER JOIN 完全不是同一量级的开销。
实操建议：
- 把
WHERE x IN (SELECT y FROM t2 WHERE ...)改成INNER JOIN t2 ON t1.x = t2.y或EXISTS (SELECT 1 FROM t2 WHERE t2.y = t1.x)；后者在子查询结果集小、且t2有合适索引时更稳 - 把
SELECT *, (SELECT z FROM t2 WHERE t2.id = t1.ref_id)拆成显式LEFT JOIN t2 ON t1.ref_id = t2.id，再选需要的字段 - 别依赖优化器“自动拉起”子查询——
EXPLAIN ANALYZE看到Nested Loop+InitPlan就是危险信号
避免在子查询中做无过滤的全表扫描
常见错误是写一个不带 WHERE 的子查询当数据源，比如 FROM (SELECT * FROM logs) AS l，然后在外层加条件。PostgreSQL 很可能先物化整个子查询结果（生成临时文件），再过滤——哪怕最终只取 10 行。
实操建议：
- 子查询里必须有明确的
WHERE过滤，且字段要有索引；例如(SELECT id, user_id FROM events WHERE created_at > '2026-01-01')比(SELECT * FROM events)安全得多 - 用
WITH时也一样：CTE 不是视图，PostgreSQL 默认按需物化，没过滤就等于提前加载全部 - 如果子查询只是为重用逻辑，考虑改用函数或物化视图（配合定期刷新）
用覆盖索引支撑子查询改写后的 JOIN
把子查询改成 JOIN 后，性能瓶颈常转移到 JOIN 字段没索引，或索引无法覆盖查询字段上。例如 JOIN users ON orders.user_id = users.id，但 users 表只在 id 上建了单列索引，而查询还要取 users.name 和 users.email，就会回表。
实操建议：
- 对被驱动表（通常是
JOIN右侧）建组合索引，顺序按ON条件字段 +SELECT中需要的其他字段；例如CREATE INDEX idx_users_id_covering ON users(id) INCLUDE (name, email) - 确认
EXPLAIN ANALYZE中Join Filter没出现在Hash Join或Merge Join外层——那说明条件没下推到索引扫描阶段 - 别在
ON里写函数，如ON UPPER(t1.code) = UPPER(t2.code)，会直接让索引失效
窗口函数替代聚合子查询时注意分区粒度
用子查询实现“每组取最新一条”（如 SELECT * FROM t1 WHERE id = (SELECT MAX(id) FROM t2 WHERE t2.group_id = t1.id)）非常慢。窗口函数能解决，但写错分区方式反而更耗资源。
实操建议：
- 优先用
DISTINCT ON (group_id) ORDER BY group_id, updated_at DESC（PG 特有，高效）；通用方案用ROW_NUMBER() OVER (PARTITION BY group_id ORDER BY updated_at DESC)，再套一层WHERE rn = 1 -
PARTITION BY字段必须有索引，否则排序开销爆炸；如果分区键本身高基数（如用户 ID），考虑加WHERE先缩小范围再开窗 - 避免在窗口函数里混用多表字段做排序，比如
ORDER BY t1.created_at, t2.score—— 跨表排序大概率触发临时文件和 filesort
真正卡住的往往不是语法怎么写，而是改写后没验证索引是否生效、没看 EXPLAIN ANALYZE 里有没有 Temp File 或 Buffers: shared read=xxx 这类提示。一次改写 + 一次真实执行计划比十次理论推演都管用。
