子查询不一定能解决自连接性能问题，因其可能引发n+1查询或反复执行相关子查询；仅当非相关且结果集极小时才更优；窗口函数才是行间比较类逻辑的正确替代方案。
为什么子查询不一定能解决自连接性能问题
直接用子查询替换自连接，往往只是把性能问题从“中间结果集爆炸”转移到“N+1查询”或“相关子查询反复执行”。比如计算员工部门内薪资排名时写成：
SELECT employee_id, salary, ( SELECT COUNT(*) FROM employees e2 WHERE e2.department_id = e1.department_id AND e2.salary >= e1.salary ) AS dept_rank FROM employees e1;
这个语句对 e1 每一行都执行一次子查询，若表有10万行，就触发10万次独立扫描——比自连接更慢。
- 相关子查询（即引用外层表字段的子查询）无法被数据库一次性优化，执行计划里通常显示为
DEPENDENT SUBQUERY - 即使加了
department_id和salary联合索引，也难避免重复索引查找开销 -
EXPLAIN中若看到type列为ALL或index且rows值巨大，基本可判定是相关子查询拖慢了整体速度
什么情况下子查询确实比自连接快
只有满足“非相关”且“结果集极小”两个条件时，子查询才可能优于自连接。典型场景是：用单值子查询过滤主表，而非逐行计算。
- 用
EXISTS替代IN判断存在性：WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id)—— 找到第一个匹配就退出，不生成中间集 - 用标量子查询获取聚合值：
SELECT name, (SELECT AVG(salary) FROM employees) AS avg_salary FROM employees—— 只执行1次，结果缓存复用 - 子查询返回常量或配置项：如
(SELECT value FROM config WHERE key = 'tax_rate')，数据库通常会物化该值
关键判断依据是 EXPLAIN 输出中子查询是否标记为 UNCORRELATED SUBQUERY，且 rows 显示为固定小数值（如1或几行）。
真正有效的替代方案：窗口函数优先于子查询
对于原本靠自连接实现的“行间比较”类逻辑（如排名、累计求和、前后行取值），ROW_NUMBER()、RANK()、LAG() 等窗口函数才是正确解法。它们在单次全表扫描中完成计算，不产生笛卡尔积。
SELECT employee_id, salary, ROW_NUMBER() OVER (PARTITION BY department_id ORDER BY salary DESC) AS dept_rank FROM employees;
- 执行计划中只会看到1次
employees表扫描，type通常是ALL或index，但无嵌套循环 - 若
department_id和salary有联合索引，还能进一步减少排序开销 - MySQL 8.0+、PostgreSQL、SQL Server 2012+、Oracle 都支持标准窗口语法，兼容性已不是障碍
如果必须用子查询，怎么写才不至于更慢
当业务逻辑强制要求子查询（例如权限校验需动态查角色表），应确保它脱离外层循环上下文，并利用物化能力。
- 用
WITH子句提前物化中间结果：WITH dept_stats AS (SELECT department_id, AVG(salary) avg_sal FROM employees GROUP BY department_id) SELECT e.name, d.avg_sal FROM employees e JOIN dept_stats d ON e.department_id = d.department_id - 避免在
SELECT列表里放子查询；改到FROM子句作为派生表，让优化器有机会重用执行计划 - 确认子查询中所有过滤条件都落在索引字段上，尤其注意隐式类型转换（如字符串字段与数字比较）会导致索引失效
最常被忽略的一点：窗口函数不是银弹，PARTITION BY 字段若高基数（如每行都不同），排序开销仍会显著上升——这时候得回头检查是否真需要按此维度分组，还是业务逻辑本身可以调整。
