ROW_NUMBER() 在多级分组中总从1重新开始，因其需配合 PARTITION BY 实现分组内编号；单层分区无法表达树状层级，须用多层嵌套 ROW_NUMBER() 逐级计算并字符串拼接，且所有层级必须共用统一 ORDER BY 字段以保证层级对齐。
ROW_NUMBER() 在多级分组中为什么总从1重新开始？
因为 ROW_NUMBER() 必须配合 PARTITION BY，否则默认对全表编号；但只写一层 PARTITION BY dept，子组（比如 team）内序号还是混的——它不理解“部门→团队→员工”这种树状层级。
真正要拼出 "1.1.5" 这种嵌套序号，得让每一级的编号都依赖上一级结果，不能靠单个 ROW_NUMBER() 一锤定音。
- 错误写法：
ROW_NUMBER() OVER (PARTITION BY dept ORDER BY emp_id)→ 只能生成每部门内的 1,2,3…，没法体现团队内偏移 - 正确思路：用多层嵌套的
ROW_NUMBER()，逐级计算，并用字符串拼接组合 - 关键约束：所有参与拼接的
ROW_NUMBER()必须共用同一ORDER BY字段（如dept, team, emp_id），否则层级对不齐
怎么拼出 "1.2.3" 这样的三级序号？
核心是把每级的 ROW_NUMBER() 结果转成字符串，再用 CONCAT 或 || 拼接。注意：必须在最外层 ORDER BY 统一控制全局排序逻辑，否则各层编号错位。
示例（PostgreSQL / SQL Server）：
SELECT
dept,
team,
emp_name,
CONCAT(
ROW_NUMBER() OVER (ORDER BY dept),
'.',
ROW_NUMBER() OVER (PARTITION BY dept ORDER BY team),
'.',
ROW_NUMBER() OVER (PARTITION BY dept, team ORDER BY emp_id)
) AS nested_id
FROM employees;
- 第一段
ROW_NUMBER() OVER (ORDER BY dept)：按部门全局排序，生成“1,2,3…” - 第二段
PARTITION BY dept ORDER BY team：每个部门内按团队排，生成“1,1,2,1…” - 第三段
PARTITION BY dept, team ORDER BY emp_id：每个团队内按员工排，生成“1,2,3…” - MySQL 用户注意：
CONCAT可用，但若字段为 NULL 会令整串变 NULL，建议加COALESCE(..., '0')
Oracle 和 PostgreSQL 对 NULL 的处理差异会影响拼接结果吗？
会，而且很隐蔽。比如某员工 team 为 NULL，在 PARTITION BY dept, team 中，所有 team IS NULL 的行会被划进同一个隐式分区，导致序号乱跳——你以为的“空团队”被当成一个合法组了。
- Oracle：
PARTITION BY dept, team中，NULL值彼此相等，会归入同一组 - PostgreSQL：行为一致，但部分旧版本对
NULLS FIRST/LAST敏感，建议显式写ORDER BY dept NULLS LAST, team NULLS LAST - 安全做法：提前用
CASE WHEN team IS NULL THEN '_UNASSIGNED' ELSE team END替换 NULL，避免分区逻辑意外合并 - 别依赖数据库默认的 NULL 处理，嵌套序号场景下，任何隐式分组都可能让 “1.1.1” 变成 “1.1.7”
性能差、查询卡住？可能是窗口函数重复扫描了三次
上面那个三层 ROW_NUMBER() 写法，表面简洁，但多数引擎（尤其 MySQL 8.0 之前、SQL Server 2016）会为每个 OVER 子句单独走一遍排序——数据量大时 I/O 和内存开销翻三倍。
- 优化方向：用 CTE 预先算好各层序号，再 JOIN 拼接，让排序只做一次
- 示例（通用写法）：
WITH ranked AS ( SELECT *, ROW_NUMBER() OVER (ORDER BY dept) AS dept_rn, ROW_NUMBER() OVER (PARTITION BY dept ORDER BY team) AS team_rn, ROW_NUMBER() OVER (PARTITION BY dept, team ORDER BY emp_id) AS emp_rn FROM employees ) SELECT dept, team, emp_name, CONCAT(dept_rn, '.', team_rn, '.', emp_rn) AS nested_id FROM ranked; - BigQuery / Snowflake 用户可忽略此问题，它们对多窗口复用排序有较好优化
- 别为了“一行写完”牺牲可读性和性能，嵌套序号本质是分步逻辑，强行压进单个 SELECT 容易掩盖执行计划缺陷
ORDER BY 字段一致性——比如部门按名称排，团队却按创建时间排，最后拼出来的 “2.5.1” 根本对应不上业务层级。序号只是表象，背后是明确的排序契约。 
