必须用 left join 而不是 inner join，因为 ceo 等 manager_id 为 null 的记录会被 inner join 过滤掉；需用 e.manager_id = m.id 正确关联上下级，字段加前缀避免歧义，coalesce 处理 null 上级，并为 manager_id 添加非唯一索引提升性能。
为什么必须用 LEFT JOIN 而不是 INNER JOIN
因为 CEO、部门负责人等角色的 manager_id 是 NULL，用 INNER JOIN 会直接把这些记录过滤掉，结果里只剩有上级的人——看起来像数据丢了，其实是连接逻辑本身就把根节点剔除了。
-
LEFT JOIN把员工表当主表（别名e），上级表当从表（别名m），确保每条员工记录都保留 - 连接条件只能是
e.manager_id = m.id，写反了（比如e.id = m.manager_id）就会查出“谁是某人的下属”，而不是“谁是某人的上级” - 如果后续加了
WHERE m.id IS NOT NULL，LEFT JOIN就退化成INNER JOIN，这个坑非常隐蔽，建议真要过滤时用HAVING或子查询，而不是在WHERE里碰m.字段
字段重命名和 NULL 上级怎么显示
所有同名字段（id、name、email）必须加前缀，否则报错 Column 'name' in field list is ambiguous，或者查出来全是 NULL。
- 员工字段统一用
e.前缀，上级字段用m.前缀，例如：e.name AS employee_name、m.name AS manager_name -
m.name对 CEO 是NULL，前端渲染可能出错，用COALESCE(m.name, '无上级')替换更安全 - 别漏选
m.id：区分“上级不存在”和“上级存在但姓名为空”，靠m.id IS NULL判断更准，比只看m.name可靠
manager_id 没索引，查询会慢到不可接受
自连接性能不取决于 JOIN 写法，而取决于数据库怎么找匹配行。没索引时，每条员工记录都要扫描全表找上级，10 万行员工 ≈ 10 亿次比较。
- 立刻执行：
CREATE INDEX idx_employee_manager_id ON employee(manager_id); - 类型必须和上级主键一致（比如
id是INT NOT NULL，那manager_id也得是INT NOT NULL） - 不要建唯一索引：
manager_id允许多个员工指向同一上级，唯一索引会报错或阻断插入 - 用
EXPLAIN看执行计划：type列要是ref或eq_ref，不是ALL
两层够用就别硬堆三层 JOIN
查“员工 → 经理 → 总监”这种固定三层关系，可以写两层 LEFT JOIN，但再往上堆，中间任意一层 manager_id 为 NULL，整行就断掉，结果不可靠。
- 三层写法示例：
e1 LEFT JOIN e2 ON e1.manager_id = e2.id LEFT JOIN e3 ON e2.manager_id = e3.id - 每多一层，结果集可能指数膨胀（尤其多人共用同一上级时）
- 真正需要任意深度（比如查某人全部汇报链），必须换
WITH RECURSIVE，MySQL 8.0+、PostgreSQL、SQL Server 支持，旧版本不行
最常被跳过的其实是索引和 NULL 处理——语法写对了，跑起来慢或结果少一半，八成卡在这两处。
