自连接本身不慢，慢的是没加索引、写错条件或该用窗口函数却硬套自连接；必须为on字段（尤其是右表别名字段）建索引，明确区分左右别名并全程带前缀，涉及相邻行比较时优先用lag/lead。
自连接本身不慢，慢的是没加索引、写错条件、或本该用窗口函数却硬套自连接。
为什么自连接容易变慢
自连接本质是把一张表当两张表用，数据库要对它做两次扫描或构建临时副本。如果没索引，JOIN 条件字段（比如 manager_id 或 parent_id）又没建索引，就会触发全表扫描 × 2，性能断崖式下跌。
- 常见错误现象：
EXPLAIN显示type = ALL，且rows值巨大 - 使用场景：组织树查询、相邻时间对比、重复数据检测
- 关键点：必须给被
ON的字段建索引，尤其是右侧别名引用的字段（如m.employee_id） - 性能影响：没索引时，10万行表自连接可能耗时秒级；加索引后通常压到毫秒级
别名写法必须明确区分左右实例
别名不是可选项，是强制要求。不加别名或别名冲突，SQL 直接报错或逻辑错乱。
-
FROM employees e JOIN employees m是标准写法，e和m必须不同，且全程保持一致 - 别名不能只在
FROM出现一次就完事——所有字段引用（SELECT、WHERE、ON）都得带前缀，否则数据库分不清你指哪一行 - 错误示例：
SELECT name, manager_id FROM employees e JOIN employees ON e.manager_id = employee_id→ 这里第二个employee_id没别名，解析失败 - 正确示例：
SELECT e.name, m.name FROM employees e LEFT JOIN employees m ON e.manager_id = m.employee_id
自连接 vs 窗口函数：什么时候该换掉 JOIN
只要涉及“和上/下一行比”，优先考虑 LAG/LEAD，而不是自连接。PostgreSQL、MySQL 8.0+、SQL Server 都支持。
- 错误信号：你的
ON条件是时间偏移（curr.date = prev.date + interval '1 day'）或序号差（p1.id = p2.id - 1） - 窗口函数优势：单次扫描，无笛卡尔积风险，语义清晰，执行计划干净
- 示例对比：
SELECT curr.date, curr.amount, LAG(curr.amount) OVER (ORDER BY curr.date) AS prev_amount FROM sales curr比自连接快 3–5 倍，且更易维护 - 例外情况：需要跨多行（比如“和前三天平均值比”），窗口函数仍适用；但若需关联非相邻行（如“找每个员工入职前最后一位离职者”），才真正需要自连接
LEFT JOIN 自连接必须小心 NULL 处理
用 LEFT JOIN 做自连接时，右侧实例字段会为 NULL，但很多人忘了在 SELECT 或 WHERE 中显式处理。
- 典型坑：
WHERE m.salary > e.salary会直接过滤掉所有m.salary IS NULL的行，导致顶层节点（如 CEO）完全消失 - 正确做法：要么改用
ON里加条件（ON e.manager_id = m.employee_id AND m.salary > e.salary），要么在WHERE里补OR m.salary IS NULL - 更安全的写法是先用
LEFT JOIN拉出全部关系，再在应用层或后续子查询中过滤，避免意外丢数据 - 如果业务上“必须有上级”才有效，那其实该用
INNER JOIN，而不是硬套LEFT
最常被忽略的其实是索引方向——自连接里，被 JOIN 到的那张“虚拟右表”的关联字段（m.employee_id）必须有索引，而不仅是左表的外键字段（e.manager_id）。这点在 EXPLAIN 输出里看 key 和 ref 字段就能确认。
