子查询适用于查单层代理关系，如“张三的直属上级”或“所在部门负责人”，前提是字段来源明确；若跨表则需JOIN或子查询关联，多层树形查询必须用WITH RECURSIVE，自连接适合固定深度展开，COALESCE仅作空值兜底，不可用于层级查找。
用子查询嵌套查某人的直属上级和部门头
直接查单层代理关系，比如“查张三的直属上级是谁、他所在部门的负责人又是谁”，用子查询最轻量。关键不是嵌套多深，而是字段是否来自同一张表。
常见错误是把 direct_manager 和 dept_head 当成能自动关联的逻辑链——它们其实是并列字段，不构成父子关系。如果 dept_head 存在但没存进员工记录里，子查询也拿不到。
- 若字段都在
employees表中：直接SELECT name, direct_manager, dept_head FROM employees WHERE name = '张三'就够了，不需要嵌套 - 若
dept_head存在另一张departments表里：得先 JOIN 或写子查询，例如(SELECT head_name FROM departments d WHERE d.id = e.dept_id) - 别在 WHERE 里写多层子查询查树形路径，比如 “找张三的上级的上级”，那不是子查询该干的事，性能会断崖式下跌
用递归 CTE 向上追溯到组织根节点
当需求变成“查张三最终汇报给谁（不管隔几层）”，就必须用 WITH RECURSIVE，子查询完全无法表达这种动态深度遍历。
MySQL 8.0+、PostgreSQL、SQL Server 都支持，但语法细节有差异。核心陷阱是递归条件写反——必须让每次 JOIN 都往父节点收拢，而不是发散。
- 起点必须明确：比如
WHERE id = 123定位张三，不能漏掉这一行 - 递归 JOIN 条件要写成
ON e.id = t.manager_id（向上查），写成e.manager_id = t.id就变成向下展开了 - 务必加
level字段并限制最大深度，否则环形引用（比如 A→B→A）会导致无限循环 - PostgreSQL 中需显式声明列类型，如
CAST(name AS TEXT)，否则递归拼接路径时可能报错
用自连接替代多层子查询查上下级链
想一次性拉出“员工→直属上级→上级的上级”三段关系，用自连接比套三层子查询更可靠、更易读。
自连接本质是把一张表当多个副本用，每个别名代表一个层级。它不递归，但适合固定深度的展开，且数据库优化器更容易命中索引。
- 别名命名要有意义：比如
e（employee）、m1（manager level 1）、m2（manager level 2） - JOIN 条件要逐级对齐：
ON e.manager_id = m1.id AND m1.manager_id = m2.id - 注意 NULL 处理：如果某人没有二级上级，
m2.name就是 NULL，别误以为是数据缺失 - 超过 3 层就别硬撑自连接了——代码爆炸，维护成本陡增，该切递归 CTE
COALESCE 不是用来查层级的，别滥用
COALESCE 只做同级字段空值兜底，不是树形查询工具。把它当“智能向上查找”用，结果一定错。
比如写 COALESCE(direct_manager, dept_head, division_lead)，看起来像在“逐级 fallback”，实际只是按顺序取第一个非 NULL 值，完全不关心这些字段之间有没有隶属关系。
- 如果
dept_head是财务部老大，而张三在技术部，这个值对张三毫无业务意义 - 所有参数必须类型一致，混用
VARCHAR和INT会在 PostgreSQL 里直接报错 - 末尾一定要加兜底值，比如
COALESCE(..., 'HR-Contact')，否则整列 NULL 会让下游报表崩掉 - 真要按规则选负责人（比如“职级≥P8 的部门头才可用”），必须换
CASE WHEN，COALESCE无条件判断能力
递归 CTE 的终止条件、自连接的层级边界、COALESCE 的类型对齐——这些地方一松懈，查出来的“负责人”就可能是错的，而且很难被肉眼发现。
