自连接必须使用不同且有意义的表别名，否则解析器无法区分同一表的多个实例而报错；ON条件需明确父子方向并带别名前缀；查完整层级须用LEFT JOIN并建索引防性能问题。
自连接必须用表别名，否则SQL报错
不加别名的自连接在所有主流数据库里都会报错，比如 MySQL 报 ERROR 1066 (42000): Not unique table/alias，PostgreSQL 是 table name "xxx" specified more than once。因为 SQL 解析器无法区分同一张表的两个逻辑实例。
实操建议：
- 给每个自连接的表实例起**不同且有意义**的别名，比如
users AS u1和users AS u2 - 别名不能重复，也不能和原表名完全一样（某些老版本 SQLite 会警告）
- WHERE 或 ON 条件里所有字段必须带别名前缀，如
u1.manager_id = u2.id，漏写会导致列歧义或意外笛卡尔积
层级数据（如组织架构）靠 ON 条件关联父子关系
自连接不是为了“把表复制一遍”，而是建模一对多中的“自身引用”关系。典型场景是员工表里 manager_id 指向同表的 id。
实操建议：
- ON 条件必须明确父子方向：通常是子表字段 = 父表主键，例如
emp.manager_id = mgr.id（emp是下属，mgr是上级） - 避免写成
emp.id = mgr.manager_id——这会反向查“谁的下属是这个人”，语义易错且结果难理解 - 如果要查多级（如直属上级 + 上上级），需嵌套自连接或用递归 CTE；两层自连接已足够覆盖大部分报表需求
LEFT JOIN 自连接才能查出顶层节点（如CEO）
用 INNER JOIN 自连接时，没有上级的记录（如 CEO 的 manager_id 为 NULL）会被直接过滤掉。这是新手最常漏掉的逻辑缺口。
实操建议：
- 查完整组织树必须用
LEFT JOIN，例如FROM employees emp LEFT JOIN employees mgr ON emp.manager_id = mgr.id - 此时
mgr.name对 CEO 行会是 NULL，可用COALESCE(mgr.name, 'Top')做兜底 - 若业务要求只显示有上级的员工，则才用 INNER JOIN；但务必确认这是显式需求，而非疏忽
性能隐患：自连接容易触发全表扫描
即使有索引，自连接的执行计划也常比单表查询高一个数量级。尤其当连接条件没走索引，或表数据量超 10 万行时，响应可能从毫秒变秒级。
实操建议：
- 确保被 JOIN 的字段（如
manager_id）建了索引，且类型与主键一致（比如都是INT NOT NULL） - 避免在 ON 条件里对字段做函数操作，例如
ON COALESCE(emp.manager_id, 0) = mgr.id会让索引失效 - MySQL 8.0+ 和 PostgreSQL 可考虑用 LATERAL JOIN 替代部分自连接场景，但前提是业务逻辑允许分步计算
别名不是语法糖，是解析器定位数据源的唯一方式；而连接方向和 JOIN 类型选错，往往比写错 WHERE 条件更难排查——因为结果看起来“差不多”，只是少了几行关键数据。
