必须用 left join 而非 inner join，因 ceo 等 manager_id 为 null 的员工会被 inner join 过滤；需用 e.manager_id = m.id 关联，字段加前缀重命名，coalesce 处理 null，并为 manager_id 建索引。
直接用 SELF JOIN 就能查出员工和直属上级的对应关系，关键不是“能不能”，而是“怎么写才不出错、不漏数据”。
为什么必须用 LEFT JOIN 而不是 INNER JOIN
因为 CEO 或部门负责人没有上级，manager_id 是 NULL。如果用 INNER JOIN，这些人会被完全过滤掉。
实操建议：
- 始终优先用
LEFT JOIN关联自身表，把员工表作为主表（别名e），上级表作为从表（别名m） -
ON e.manager_id = m.id是核心连接条件，不是e.id = m.manager_id - 如果只想要有上级的员工，再加
WHERE m.id IS NOT NULL，但这是后置筛选，不是连接逻辑
字段重命名和 NULL 上级的显示处理
两个表同名字段（如 name、id）会冲突，不重命名查出来全是 NULL 或报错。
实操建议：
- 员工字段全部加前缀
e.，上级字段加m.，例如：e.name AS employee_name、m.name AS manager_name - 用
COALESCE(m.name, '无上级')把NULL上级转成可读字符串，避免前端渲染异常 - 别忘了选
m.id—— 有时需要区分“上级不存在”和“上级存在但姓名为空”
性能隐患：没加索引时 SELF JOIN 很慢
哪怕只有几千行，manager_id 没索引，LEFT JOIN 就会触发全表扫描 × 全表扫描，响应时间从毫秒变秒级。
实操建议：
- 立刻检查并添加索引：
CREATE INDEX idx_employee_manager_id ON employee(manager_id); - 不要只建在
id上——id默认主键已有索引，但manager_id几乎总是缺失 - 如果表经常更新，避免在
manager_id上建唯一索引（多人可汇报给同一上级）
最常被跳过的其实是索引和 NULL 处理——写对了语法，跑起来慢或结果少一半，八成卡在这两处。
