自连接慢的主因是缺失索引、条件错误或误用join替代窗口函数；需为on右侧字段建索引，规范使用表别名，left join过滤条件应置于on而非where，相邻行比较优先用lag()/lead()。
为什么自连接一跑就慢？先看EXPLAIN里的type = ALL
自连接本身不慢，慢的是没索引、条件写错、或本该用窗口函数却硬套JOIN。数据库执行SELECT * FROM employees e1 JOIN employees e2 ON e1.manager_id = e2.id时，本质是把一张表当两张扫描——如果manager_id和id都没索引，就会触发两次全表扫描，rows值翻倍暴涨，EXPLAIN里直接显示type = ALL。
常见错误现象：EXPLAIN中key为NULL，rows接近表总行数 × 表总行数；查询耗时从毫秒跳到秒级甚至超时。
- 必须为
ON右侧字段建索引（如m.employee_id），因为JOIN时右表是被驱动表，索引在这里最有效 -
manager_id字段选择性低（比如大量NULL或重复值）时，单独建索引效果有限，考虑加WHERE manager_id IS NOT NULL提前过滤 - 复合索引更优：若常查
WHERE department_id = ? AND manager_id = ?，建(department_id, manager_id)比单列索引快得多
FROM employees e JOIN employees m别名不是装饰，是执行前提
不加别名或别名冲突，SQL会报错或返回错乱结果。数据库无法区分name来自哪一行——是员工本人，还是其经理？所有字段引用都必须带前缀，包括SELECT、WHERE、ON。
错误示例：SELECT name, manager_id FROM employees e JOIN employees ON e.manager_id = employee_id → 第二个employee_id没别名，解析失败。
- 别名必须全程一致：
FROM employees e LEFT JOIN employees m之后，所有e.和m.不能混用或漏写 - LEFT JOIN自连接时，右侧字段可能为
NULL，WHERE m.salary > e.salary会把所有m.salary IS NULL的行过滤掉，应改用AND m.salary > e.salary放在ON里，或显式写WHERE m.salary IS NOT NULL AND m.salary > e.salary - 避免用旧式逗号语法：
FROM employees a, employees b WHERE a.manager_id = b.id语义模糊，易漏WHERE条件导致笛卡尔积
相邻行比较？别写JOIN p1 ON p1.id = p2.id - 1，改用LAG()
只要逻辑是“和上一行比”“和下一行比”“按时间顺序取前值”，就该换窗口函数。自连接写这种逻辑，等于强制数据库做排序+关联+去重三重开销，而LAG()单次扫描就能完成。
错误信号：ON条件含算术偏移（如p1.date = p2.date + INTERVAL '1 day'）、序号差（p1.id = p2.id - 1）、或范围比较（p1.amount BETWEEN p2.min_val AND p2.max_val）。
- MySQL 8.0+、PostgreSQL、SQL Server均支持
LAG()/LEAD()，写法简洁：SELECT date, amount, LAG(amount) OVER (ORDER BY date) AS prev_amount - 性能差距明显：百万行销售数据，自连接查“昨日销量”要800ms，
LAG()压到120ms以内 - 例外情况：需跨非相邻行（如“找每个员工入职前最后一位离职者”），窗口函数表达困难，才真正需要自连接
LEFT JOIN自连接后WHERE条件写错，结果直接少一半
LEFT JOIN本意是保留左表全部记录，但一旦在WHERE里对右表字段加非空限制（如WHERE m.status = 'active'），数据库会把它转成隐式INNER JOIN，所有右表无匹配的行都被丢弃。
- 正确做法：把右表过滤条件挪进
ON子句，LEFT JOIN employees m ON e.manager_id = m.id AND m.status = 'active' - 若必须在
WHERE中判断右表字段，记得补OR m.id IS NULL，否则逻辑变形 - 测试时务必查NULL值占比：执行
SELECT COUNT(*) FROM employees e LEFT JOIN employees m ON e.manager_id = m.id WHERE m.id IS NULL，确认是否真有无上级的员工；否则优化后反而漏数据
实际调优时，最容易被忽略的是索引建在谁身上——不是左表manager_id，而是右表id字段；还有就是把WHERE当万能过滤器，忘了它对LEFT JOIN的隐式转换效应。
