“包含关系”指组织架构中部门与其所有下级部门构成的树状层级关系；SQL中需用递归CTE展开路径（如'总部/华东/上海'），再基于路径过滤或分组，最后用窗口函数排名，直接PARTITION BY dept_id仅限本级，无法覆盖跨层级包含逻辑。
组织架构中“包含关系”指什么？
在SQL里处理组织架构的“包含关系”，通常指树状层级：比如 dept_id 和 parent_dept_id 构成父子关系，一个部门可能下辖多个子部门，形成多级嵌套。这种结构本身不直接支持窗口函数的 PARTITION BY —— 因为 PARTITION BY 只能按字段值做扁平分组，无法递归识别“本部门及其所有下级部门”这个动态范围。
直接用 PARTITION BY dept_id 为什么不行？
常见误操作是写成：ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC)。这只会给每个部门内部员工排名，但完全忽略“某员工属于子部门，而子部门属于上级部门”这一包含逻辑。如果你要的是“整个华东大区（含上海、南京、杭州等所有子部门）内薪资 Top 10”，这种写法连数据范围都错了。
- 它把每个部门当成孤立单元，无法聚合跨层级的数据
-
PARTITION BY不接受子查询或递归表达式 - 没有
WITH RECURSIVE预处理，窗口函数看不到“向上穿透”的组织路径
正确做法：先展开路径，再窗口排名
必须分两步：第一步用递归 CTE 构建出每个节点的完整路径（例如 '总部/华东/上海/研发部'），第二步基于该路径做分组或过滤，最后才用窗口函数排名。
示例（PostgreSQL / MySQL 8.0+）：
WITH RECURSIVE org_path AS (
SELECT dept_id, parent_dept_id, dept_name, CAST(dept_name AS CHAR(500)) AS path, 0 AS level
FROM departments WHERE parent_dept_id IS NULL
UNION ALL
SELECT d.dept_id, d.parent_dept_id, d.dept_name,
CONCAT(op.path, '/', d.dept_name),
op.level + 1
FROM departments d
INNER JOIN org_path op ON d.parent_dept_id = op.dept_id
)
SELECT
e.name, e.salary,
RANK() OVER (ORDER BY e.salary DESC) FILTER (WHERE op.path LIKE '%华东%') AS huadong_rank
FROM employees e
JOIN org_path op ON e.dept_id = op.dept_id;
关键点：
-
FILTER (WHERE ...)是 PostgreSQL 语法；MySQL 需改用条件聚合或子查询包裹 - 若要“每个大区独立排名”，应
PARTITION BY op.path REGEXP '^总部/(华东|华北|华南)'（MySQL）或用SUBSTRING_INDEX提取一级区域 - 路径字符串长度需预估足够，避免截断导致误匹配
容易被忽略的稳定性陷阱
即使路径生成正确，排名结果仍可能因排序不稳定而波动——尤其当多人同薪时。RANK() 或 DENSE_RANK() 在 ORDER BY salary DESC 后未加二级排序，数据库可能任意选择先后顺序。生产环境必须补上确定性锚点：
- 加
, emp_id ASC或, hire_date DESC保证同薪者顺序一致 - 若用
ROW_NUMBER()做唯一分页标识，这点更是硬性要求 - 注意不同数据库对
NULL的默认排序行为（NULLS FIRSTvsNULLS LAST），路径字段若允许为空，需显式声明
真正难的不是写对窗口函数，而是把“包含关系”翻译成数据库可计算的扁平化上下文——路径展开只是开始，后续过滤、分组、排序每一步都得和业务定义严丝合缝。
