left join是查员工-经理关系的唯一选择，因ceo等manager_id为null的员工会被inner join过滤；正确写法为select e.name as employee, m.name as manager from employees e left join employees m on e.manager_id = m.id，需用coalesce处理null、别名统一、on条件不写反、manager_id建索引。
为什么LEFT JOIN是查员工-经理关系的唯一选择
因为CEO或部门负责人没有上级，manager_id为NULL——用INNER JOIN会直接丢掉这些人，看起来像数据缺失，其实是逻辑过滤。只有LEFT JOIN能保留所有员工记录，让上级字段自然为NULL。
常见错误现象：SELECT e.name, m.name FROM employees e INNER JOIN employees m ON e.manager_id = m.id跑出来只有23条记录，但表里明明有100个员工；一查发现CEO和5个部门主管全没了。
-
COALESCE(m.name, 'Top')可把NULL替换成可读标识，但别在WHERE里写m.name IS NOT NULL，否则LEFT JOIN就退化成INNER JOIN - 别名必须全程一致：左表始终叫
e（employee），右表始终叫m（manager），混用emp/mgr容易在ON条件里写反 - ON条件永远是
e.manager_id = m.id，反过来写e.id = m.manager_id就查成“谁是张三的下属”了
manager_id没索引，查询慢十倍不是夸张
自连接性能瓶颈不在JOIN语法本身，而在数据库怎么找匹配行。驱动表（通常是子级e）每行都要去父级表扫一遍找manager_id对应记录。10万员工，没索引≈10亿次全表扫描。
- 必须给
manager_id建单列索引，类型要和父级主键（如id）严格一致（比如都是INT NOT NULL） - 用
EXPLAIN看执行计划：type列要是ref或eq_ref，不是ALL - 父级主键
id也要确认能走索引——联合主键或自定义聚簇方式下，id不一定自动高效
查三层汇报关系时，JOIN堆叠的隐性陷阱
写e1 LEFT JOIN e2 ON e1.manager_id = e2.id LEFT JOIN e3 ON e2.manager_id = e3.id看似直观，但中间任一manager_id为NULL，整行就消失。CEO的直属经理能查到，但经理的经理（即CEO自己）在结果里是NULL，不是空值而是整行被截断。
- 超过两层后，结果集可能指数膨胀：一个总监管10个经理，每个经理管5个员工，三层JOIN产出就是50行，而非你想看的“汇报链”
- 真要查某人全部上级（不限深度），必须换
WITH RECURSIVE，MySQL 8.0+、PostgreSQL、SQL Server支持，旧版SQLite不支持 - 筛选父级身份（比如只看“部门负责人”当上级），条件必须写在ON里：
AND m.is_dept_head = 1，写在WHERE里会把无上级的员工也踢掉
字段都在同一张表时，别硬套嵌套查询
如果direct_manager和dept_head都是employees表的字段，它们是并列关系，不是父子链——dept_head没存进员工记录里，子查询也拿不到。这时候SELECT name, direct_manager, dept_head FROM employees WHERE name = '张三'就够了。
只有当dept_head存在另一张departments表里，才需要JOIN或子查询，例如(SELECT head_name FROM departments d WHERE d.id = e.dept_id)。
容易被忽略的点：自连接只解决固定层级的横向关联，它不等价于树形遍历。真正复杂的组织架构查询，得靠递归CTE或应用层拼接，而不是靠堆JOIN。
