自连接慢因SQL Server默认用嵌套循环致O(n²)复杂度，无索引时全表扫描两次；逗号语法、WHERE条件未覆盖索引键加剧性能问题；CTE+ROW_NUMBER仅在分组取Top N等特定场景有效。
自连接为什么慢？先看执行计划里的嵌套循环
SQL Server 对 self-join 默认倾向使用嵌套循环（Nested Loops），尤其当两个别名表都没走索引时，复杂度直接变成 O(n²)。比如对 10 万行的用户表做一次无条件自连接，物理读可能飙升到千万级——这不是数据量问题，是连接方式没压住。
常见错误现象：SELECT * FROM users u1 JOIN users u2 ON u1.dept_id = u2.dept_id 执行超时、CPU 持续 95%、STATISTICS IO 显示大量逻辑读。
- 别名表没加索引：
dept_id列缺失非聚集索引，SQL Server 只能全表扫描两次 - WHERE 条件写在 JOIN 后但没覆盖索引键：比如加了
AND u1.status = 1，但索引只建在dept_id上，导致索引失效 - 用逗号语法写自连接（
FROM users u1, users u2）：SQL Server 优化器更难推导连接谓词，容易选错计划
CTE + ROW_NUMBER 能替代自连接？看场景再决定
CTE 本身不提升性能，ROW_NUMBER() 也不是万能加速器——它只在「需要按组排序后取 Top N」或「消除重复逻辑」时才有价值。盲目套用反而多一层排序开销。
适用场景举例：查每个部门工资前 3 的员工（不是“所有员工两两比对”）
u1
- 如果目标是“找同部门里薪资差超过 5000 的两人”，CTE +
ROW_NUMBER无法替代自连接，必须老实用 JOIN -
PARTITION BY字段必须和自连接的关联字段一致，否则分组错位，结果不可靠 -
ORDER BY必须有确定性：如果salary有重复，要补上user_id避免ROW_NUMBER结果不稳定
真正有效的提速组合：索引 + INNER JOIN 显式写法 + 连接提示
高性能自连接的核心从来不是语法糖，而是让优化器看清数据分布并选对算法。以下三步缺一不可：
- 在连接列上建覆盖索引：
CREATE NONCLUSTERED INDEX IX_users_dept_id_salary ON users(dept_id) INCLUDE (name, salary);—— 把JOIN和SELECT需要的列都塞进索引叶级 - 强制用
INNER JOIN代替逗号语法，并把过滤条件写进ON子句（不是WHERE），例如：ON u1.dept_id = u2.dept_id AND u1.status = 1 AND u2.status = 1 - 对中等数据量（10~50 万行）且内存充足时，可加
OPTION (HASH JOIN)提示，避免嵌套循环；但上线前务必在生产镜像环境验证，HASH JOIN会吃更多内存，可能触发tempdbspill
错误示范：OPTION (LOOP JOIN) —— 这等于告诉 SQL Server “就用最慢的方式”，除非你明确知道驱动表极小且被驱动表有唯一索引，否则别碰。
最容易被忽略的坑：NULL 值和统计信息过期
自连接结果莫名少数据？大概率是连接字段含 NULL。SQL Server 中 NULL = NULL 返回 UNKNOWN，不会匹配成功。而 dept_id 字段如果有 5% 是 NULL，那这部分记录在自连接中就彻底消失了。
另一个隐形杀手是过期的统计信息。SQL Server 依赖统计信息估算行数来选连接算法，如果表数据更新频繁但没更新统计信息，优化器可能以为只有 100 行，实际已有 50 万，结果硬生生选了嵌套循环。
- 检查 NULL 比例：
SELECT COUNT(*) * 100.0 / (SELECT COUNT(*) FROM users) FROM users WHERE dept_id IS NULL; - 更新统计信息：
UPDATE STATISTICS users WITH FULLSCAN;（大数据量慎用，可用SAMPLE 30 PERCENT替代） - 如果业务允许，把
dept_id设为NOT NULL并加默认值，比在查询里写ISNULL(u1.dept_id, -1) = ISNULL(u2.dept_id, -1)更干净
