必须用 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 处理——写对了语法，跑起来慢或结果少一半，八成卡在这两处。