自连接必须用有业务含义的表别名，否则因语义歧义报错；left join保留无上级记录，inner join仅返回有上级的记录；两层自连接适用于固定深度查询，超两层应改用递归cte；manager_id字段须建索引以避免性能暴跌。
为什么自连接必须用表别名
不加别名的 FROM employees JOIN employees 在所有主流数据库里都会报错，比如 MySQL 的 ERROR 1066 (42000): Not unique table/alias。SQL 解析器根本分不清哪个 id、哪个 manager_id 属于哪一边——它不是语法错，是语义歧义。
必须给同一张表起两个不同且有业务含义的别名，比如 employees e（员工）和 employees m（经理），不能用 e1/e2 这类无意义命名。
所有字段引用都得带前缀：e.name、m.id，漏掉任意一个就会触发 Column 'name' in field list is ambiguous。
LEFT JOIN 和 INNER JOIN 到底怎么选
关键看你要不要保留顶层节点（比如 CEO 或根分类）。INNER JOIN 只返回有明确上级的记录，LEFT JOIN 才能保住 manager_id IS NULL 的行。
- 查“每个员工及其直属上级”且要包含 CEO → 用
LEFT JOIN - 查“所有有直属上级的员工” →
INNER JOIN更快，但这是业务约束，不是默认选项 - 统计每个经理带多少人，必须用
LEFT JOIN+GROUP BY m.id+COUNT(e.id)，否则 CEO 行直接消失
注意：把本该写在 ON 里的父级筛选条件（如 m.is_dept_head = 1）错放到 WHERE，会让 LEFT JOIN 变相退化成 INNER JOIN，漏掉所有无上级的记录。
两层自连接够用，别硬堆三层
查“员工 → 直属上级 → 上上级”这种固定深度，两层 JOIN 清晰可控；写到第三层（e → m1 → m2）后，只要中间某一级 manager_id 为 NULL，整行就没了，结果不可靠。
示例中 JOIN employees m1 ON e.manager_id = m1.id 是第一层，JOIN employees m2 ON m1.manager_id = m2.id 是第二层——方向永远是子级指向父级，不能反着写成 ON m1.id = m2.manager_id。
超过两层就该换递归 CTE：WITH RECURSIVE 支持任意深度，还能控制层级上限、防循环，但 MySQL 8.0+、PostgreSQL、SQL Server 才原生支持，旧版 SQLite 需升级。
manager_id 字段没索引，查询会慢十倍
自连接时，数据库通常以子级表（如 e）为驱动表，对每一行去父级表找匹配。如果 manager_id 没索引，就是嵌套全表扫描，10 万行员工数据可能触发上亿次随机 IO。
确保 manager_id 有单列索引，且类型与父级主键严格一致（比如都是 INT NOT NULL）。别忽略父级主键（如 id）是否真能走索引——联合主键或自定义聚簇方式下，id 不一定自动有高效索引。
递归 CTE 虽灵活，但查“每个员工及其直属上级+上上级”的宽表结构时，还是得靠有限层自连接；CTE 更适合查“某员工的所有祖先”这类树形遍历场景。
