查“每个员工的直属上级”必须用自连接，因为上级信息就在同一张employees表中，通过manager_id指向其他员工的emp_id；普通join无法关联外部表，拆表破坏一致性，唯有用别名e和m实现角色分离，并通过e.manager_id = m.emp_id建立关联。
查“每个员工的直属上级”为什么非得自连接？
因为上级信息就藏在员工表自己里面——manager_id字段存的是另一个emp_id，不是部门ID也不是外部表主键。普通JOIN连不到外部表，强行拆表又破坏数据一致性。这时候必须把同一张表当两个角色用：employees e（员工）和employees m（上级），靠e.manager_id = m.emp_id建立逻辑关联。
常见错误包括：
- 漏写表别名，触发
ERROR 1066: Not unique table/alias - 用
INNER JOIN导致CEO这类manager_id IS NULL的记录直接消失 -
ON条件写反成m.manager_id = e.emp_id，结果全连错人
展示分类层级时，为什么LEFT JOIN比INNER JOIN更安全？
树形结构里，一级分类（如“电子产品”）没有父分类，parent_id是NULL。如果用INNER JOIN categories t1 ON t1.parent_id = t2.id，这一行直接被过滤掉，整棵树缺根。
正确做法是：
- 用
LEFT JOIN确保子节点不因父节点缺失而丢失 - 给重复字段加明确别名：
t1.name AS category_name、t2.name AS parent_name - 在
parent_id字段上建索引，否则大表JOIN性能断崖下跌
为什么硬写三层自连接查“本人→上级→上上级”容易漏数据？
三层自连接本质是e → m1 → m2，但只要中间某环断裂（比如m1.manager_id IS NULL），整条链就崩了——该员工不会出现在结果里，哪怕他本人和直属上级都存在。
这种写法只适合深度绝对固定且≤3的场景（如省-市-区），而且：
- 每加一层就得重写SQL，无法适配动态新增的层级
- 字段前缀容易混淆：
m1.name和m2.name含义不同，但命名没业务语义 - WHERE条件若误写
m2.name IS NOT NULL，会二次过滤掉无上上级的员工
真正需要递归CTE的时刻：查“某部门所有下属部门”
自连接只能拉平固定层数，而“所有下属”是动态深度问题。比如查ID=5的部门，它下面可能有3级、5级甚至循环引用（A→B→A）。这时必须用WITH RECURSIVE：
锚点部分查出ID=5本身，递归部分不断JOIN找它的子部门，终止条件隐含在JOIN结果为空或level 里。MySQL默认递归上限1000层，PostgreSQL建议显式加深度保护——不然一个脏数据就能卡死整个连接。
最容易被忽略的是路径拼接：如果要生成"tech/backend/api"这种可排序路径，必须从锚点就开始CAST和CONCAT，中途不能换类型，否则隐式转换会截断或报错。
