窗口函数无法直接生成树状图序号，必须配合递归cte；“1.2.3”类序号本质是路径拼接结果，需先递归构造祖先路径再格式化，强行仅用窗口函数会导致层级断裂或重复。
窗口函数无法直接生成树状图序号，必须配合递归CTE
SQL标准中没有“树状图序号”这种内置概念，ROW_NUMBER()、RANK()等窗口函数只按单层排序分组，无法感知父子层级关系。你看到的“1.2.3”或“001.002.001”这类序号，本质是路径拼接结果，必须先构造出完整祖先路径，再格式化。强行只用窗口函数（比如在非递归查询上套STRING_AGG()）会漏掉中间层级，导致序号断裂或重复。
PostgreSQL / SQL Server：用RECURSIVE CTE + STRING_AGG生成带前导零的层级序号
以员工组织架构为例（id、name、manager_id），核心是两步：递归展开路径 → 拼接并补零。注意STRING_AGG()在不同数据库中默认分隔符和排序行为不同，且不支持直接格式化数字位数。
- PostgreSQL需用
LPAD(CAST(id AS TEXT), 3, '0')补零，再STRING_AGG(... ORDER BY level)保证从根到叶顺序 - SQL Server要用
FORMAT(id, '000')（2012+）或RIGHT('000' + CAST(id AS VARCHAR), 3)，且STRING_AGG()必须显式写WITHIN GROUP (ORDER BY level) - MySQL 8.0+不支持
STRING_AGG，得用GROUP_CONCAT替代，但无法在递归CTE里直接聚合，需外层JOIN再拼接
避免ORDER BY干扰递归层级顺序
常见错误是在递归CTE的锚点或递归成员里加ORDER BY——这在大多数数据库中语法非法，且即使允许（如某些PostgreSQL变体），也会打乱level计数逻辑，导致子节点序号错位。层级序号的“先后”只由树结构决定，不是查询输出顺序。
- 正确做法：在递归CTE内只用
SELECT ... FROM t JOIN cte ON t.manager_id = cte.id，不加ORDER BY - 补零和拼接必须放在CTE外部的最终
SELECT中，否则递归过程无法稳定引用父级已生成的序号字符串 - 若需按部门/姓名二次排序显示，应在最外层
ORDER BY tree_path，而非在CTE内部
性能瓶颈往往卡在字符串拼接而非递归本身
当树深超过10层、节点超万量级时，STRING_AGG对每行重复拼接长字符串（如'001.005.012.007.001'）会引发内存与CPU陡增。Oracle用户尤其要注意：LISTAGG有4000字节默认限制，超长路径直接报ORA-01489错误。
- 缓解方式：用
SUBSTR(..., 1, 100)截断路径，或改用整数数组（PostgreSQLint[]）暂存ID序列，最后再批量格式化 - 索引建议：确保
manager_id字段有索引，否则递归JOIN会全表扫描；根节点（manager_id IS NULL）最好也单独建索引 - 别忽略NULL处理：
COALESCE(manager_id, 0)可能掩盖真实根节点，应严格用IS NULL判断
真正麻烦的是跨数据库移植——SQLite没递归CTE，MySQL旧版没窗口函数，而拼接逻辑又高度依赖各库字符串函数特性。写一次就要测三遍，而且补零位数一旦定死（比如三位），后期ID突破1000就得重构整个路径生成逻辑。
