自连接必须用不同且有意义的表别名（如e和m），否则SQL解析器无法区分同一表的两个逻辑实例，导致报错（如MySQL ERROR 1066）；所有字段引用须带前缀（e.name、m.name），ON条件需明确方向，LEFT JOIN可保留无上级的CEO行，两层自连接优于三层，深层关系宜用递归CTE。
必须用表别名区分两个逻辑实例，否则所有主流数据库都会报错，比如 MySQL 的 ERROR 1066 (42000): Not unique table/alias。
为什么自连接不加别名就报错
SQL 解析器看到 FROM employees JOIN employees 时，根本分不清哪个 id、哪个 manager_id 属于哪一边。它不是“语法错误”，而是语义歧义——连字段都绑定不上。
- 别名必须不同且有意义，比如
employees e和employees m，不能写成e1和e2这种无业务含义的命名 - 老版本 SQLite 会警告
table name "employees" specified more than once，PostgreSQL 直接拒绝执行 - 所有字段引用必须带前缀：
e.name、m.name，漏掉任意一个就会触发列名不明确错误
LEFT JOIN vs INNER JOIN：顶层节点是否要保留
组织架构里 CEO 没有上级，manager_id 是 NULL。用 INNER JOIN 会直接丢掉这一行；用 LEFT JOIN 才能保全整棵树。
-
FROM employees e LEFT JOIN employees m ON e.manager_id = m.id→ CEO 行中m.name为 NULL - 用
COALESCE(m.name, 'Top')可兜底显示文字，但注意别在 WHERE 里写m.name IS NOT NULL，否则又过滤掉了顶层 - 只有明确要求“只查有直属上级的员工”时才用
INNER JOIN，这不是默认选项，而是业务约束
两层自连接就够用，别硬写三层以上
查“本人→直属上级→上上级”这种固定深度，两层自连接清晰、可控、索引友好；一旦写到第三层（如 JOIN employees m2 ON m1.manager_id = m2.id），可读性断崖下降，且容易因数据缺失导致中间结果为空而整行消失。
- 三层自连接实际等价于
e → m1 → m2，但若某员工的直属上级没有上级（m1.manager_id IS NULL），该行在m2上就匹配失败，整条记录被剔除 - 真要查任意深度，优先走递归 CTE（MySQL 8.0+ / PostgreSQL / SQL Server），而不是堆 JOIN
- 确保
manager_id字段有索引，类型与id严格一致（比如都是INT NOT NULL），否则 JOIN 会退化成全表扫描
递归 CTE 替代方案的边界在哪里
递归 CTE 不是万能银弹。它适合查“某节点的所有后代”或“所有祖先”，但不适合查“每个员工及其直属上级+上上级”的宽表结构——这时候还是得靠有限层自连接。
- 递归查询必须设终止条件，比如
WHERE t.level ，否则遇到循环引用（A→B→A）直接崩溃 - MySQL 8.0 以下不支持
WITH RECURSIVE，硬上会导致语法错误，别指望兼容 - 用
ARRAY（PostgreSQL）或hierarchyid（SQL Server）存路径比字符串拼接更安全，但它们是数据库特有能力，跨平台项目慎用
真正容易被忽略的不是语法，而是数据质量：manager_id 指向不存在的 id、出现自引用（manager_id = id）、或存在环状结构，这些都会让自连接或递归查询行为失常，上线前必须校验。
