self join 是同一张表与自身关联的查询方式，适合查询员工与直接主管的一级关系；需用别名区分逻辑表，left join 避免丢失无主管员工，on 条件为 e.manager_id = m.id，manager_id 字段必须建索引以保障性能。
Self JOIN 是什么，为什么它适合查员工-主管关系
员工表里通常用 manager_id 字段指向同一张表的 id，这种“自己连自己”的结构天然适合 Self JOIN。不用写递归 CTE 或多次子查询，一条 JOIN 就能拉出直属上下级对——前提是层级只有一级（比如只查“谁是谁的直接主管”）。如果要查祖辈、曾祖辈主管，Self JOIN 就得嵌套或换方案。
常见错误是漏掉别名，导致字段歧义：SELECT id, name, manager_id 会报错，因为两个实例的 id 冲突。必须给表起别名，比如 e（employee）和 m（manager）。
写出可读又安全的 Self JOIN 查询
核心是把同一张员工表当作两张逻辑表来用：一张代表员工，一张代表他们的主管。关键点：
- LEFT JOIN 比 INNER JOIN 更稳妥——有些员工（如 CEO）
manager_id为 NULL，INNER JOIN 会把他们过滤掉 - ON 条件必须是
e.manager_id = m.id，不是e.id = m.manager_id（后者查的是“谁的下属是这个主管”，语义反了） - SELECT 列要带别名前缀，比如
e.name AS employee_name、m.name AS manager_name - 加
WHERE m.id IS NOT NULL可单独筛出有主管的员工；加WHERE e.manager_id IS NULL能快速定位顶层管理者
示例：
SELECT e.id AS employee_id, e.name AS employee_name, m.name AS manager_name, m.id AS manager_id FROM employees e LEFT JOIN employees m ON e.manager_id = m.id;
两层及以上层级时 Self JOIN 的局限性
想查“员工 → 主管 → 主管的主管”，可以再加一层 JOIN：
SELECT e.name AS employee, m1.name AS manager, m2.name AS grand_manager FROM employees e LEFT JOIN employees m1 ON e.manager_id = m1.id LEFT JOIN employees m2 ON m1.manager_id = m2.id;
但问题很快出现：
- 每多一层，SQL 长度和维护成本线性上升
- 数据库优化器可能无法高效处理深度 JOIN，尤其数据量大时性能骤降
- 无法动态适配任意深度（比如有的链长 2 级，有的长 5 级），硬编码层级数会漏数据或报错
- MySQL 8.0 以前不支持递归 CTE，这时候真要查完整树形结构，Self JOIN 不是解法，得用临时表+循环或应用层拼装
容易被忽略的 NULL 和索引问题
Self JOIN 性能差？大概率是没在 manager_id 上建索引。这个字段是 JOIN 的驱动列，没有索引会导致全表扫描两次。
另一个坑是 NULL 处理：
-
manager_id允许 NULL 是合理的（CEO 没主管），但 JOIN 条件e.manager_id = m.id自动跳过 NULL 行，所以 LEFT JOIN 后m.name为 NULL 才代表无主管——别误判成数据异常 - 如果业务要求显示 “Top Level” 替代 NULL，可以用
COALESCE(m.name, 'Top Level')，但注意这掩盖了原始 NULL 状态，后续统计时可能出偏差 - 某些旧版 PostgreSQL 对自关联 NULL 的处理有细微差异，建议在目标环境执行
EXPLAIN确认执行计划是否走索引
