必须用left join才能完整列出所有员工（包括ceo），因inner join会丢弃manager_id为null的记录；典型写法为select e.name as employee, m.name as manager from employees e left join employees m on e.manager_id = m.id，其中m.name对ceo为null，可用coalesce(m.name, 'top')替换。
查员工和直属上级，必须用 LEFT JOIN
要完整列出所有员工（包括 CEO 这类没有上级的人），LEFT JOIN 是唯一选择。用 INNER JOIN 会直接丢掉 manager_id IS NULL 的记录，看起来像数据丢失，其实是逻辑过滤掉了。
- 典型写法：
SELECT e.name AS employee, m.name AS manager FROM employees e LEFT JOIN employees m ON e.manager_id = m.id -
m.name在 CEO 行是NULL，这是正常行为；想显示“Top”可用COALESCE(m.name, 'Top') - 别名
e和m必须全程一致，不能一半写emp一半写e - 如果在
WHERE里加m.name IS NOT NULL，LEFT JOIN就退化成INNER JOIN，这个坑非常隐蔽
ON 条件写反了，结果就全错
自连接不报语法错，但逻辑一错，结果就完全颠倒——比如把“谁是张三的上级”查成“谁是张三的下属”，而你根本发现不了。
- 正确方向永远是：子级的
manager_id指向父级的id，即e.manager_id = m.id - 错误写法如
e.id = m.manager_id或m.manager_id = e.id，会导致匹配关系反转 - 别名语义要清晰：
e代表员工（子级），m代表经理（父级），别用t1/t2这类无意义命名 - 字段引用必须带前缀，漏掉任意一个就会触发
Column 'name' in field list is ambiguous
manager_id 没索引，查询可能慢十倍
自连接性能不取决于 JOIN 本身，而取决于数据库怎么找匹配行。没索引时，每条员工记录都要扫一遍全表找上级，10 万行员工 ≈ 10 亿次扫描。
- 必须给
manager_id建单列索引，类型需和父级主键严格一致（比如都是INT NOT NULL） - 确认父级主键（如
id）真能走索引——联合主键或自定义聚簇方式下，id不一定自动高效 - 用
EXPLAIN看执行计划：type列要是ref或eq_ref，不是ALL - 别名长度不影响性能，但
e/m比employee_table_alias_1更易读、少出错
超过两层就别硬堆 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 支持，旧版 SQLite 不行 - 递归 CTE 能防循环、设层级上限，但写法和调试复杂度远高于自连接
manager_id 没索引 + 把父级筛选条件塞进 WHERE。这三个点卡住，查出来的数据看着对，其实全是错的。
