路径顺序反因拼接方向错：查祖先时需r.path || t.name，锚点path不能为空，MySQL需足够长CAST，ROW_NUMBER()须锚点显式定义且递归部分继承，字段类型顺序必须严格一致。
递归CTE查路径时，为什么拼出来的顺序总是反的
路径拼反不是语法错，而是锚点和递归部分的拼接方向没对齐。比如查某节点的所有祖先（向上找父节点），锚点是id = 123，递归部分就得用ON t.id = r.parent_id，让每次查的是“当前结果的父”，然后路径拼接必须是r.path || ' → ' || t.name（PostgreSQL）或CONCAT(r.path, ' → ', t.name)（SQL Server）——注意r.path在前，代表已有的路径；t.name在后，代表新加入的上级节点。
常见错误：
- 把
t.name || ' → ' || r.path当向上查路径，结果变成“自己→子→孙”，实际是向下展开 - 锚点里
path初始值设成空字符串''，第一层拼接就丢掉起始节点名 - MySQL中
CAST(name AS CHAR(200))长度不够，长路径被静默截断，看不出错但数据不全
ROW_NUMBER()怎么加进递归CTE里控制排序和层级展示
ROW_NUMBER()不能直接套在递归CTE顶层SELECT里用，必须在锚点和递归部分都显式定义并保持字段顺序一致。它主要用来做两件事：按层级内顺序编号（比如同级兄弟排座次），或生成可排序的整型路径标识（替代字符串拼接）。
关键操作：
- 锚点中要写明
1 AS rn，不能只靠ROW_NUMBER() OVER(...)动态算——递归部分无法引用未定义列 - 递归部分的
rn得用CTE.rn * 10 + ROW_NUMBER() OVER (ORDER BY t.sort_order)这类方式继承+扩展，否则所有子节点rn都重复为1 - 如果目标是树形缩进展示，推荐用
REPLICATE(' ', r.level) || t.name而非依赖rn，更直观也更少出错 - SQL Server里
ORDER BY GETDATE()这种写法纯属取巧，真实业务必须用确定性字段（如sort_weight或created_at）排序，否则结果不可重现
不同数据库对递归CTE + ROW_NUMBER()的字段一致性要求有多严
MySQL 8.0最敏感：锚点和递归部分的字段数量、类型、顺序必须完全一致，差一个CAST都报Recursive reference to CTE 'tree' not allowed。PostgreSQL稍松，但path字段若一边是TEXT一边是VARCHAR(100)，仍可能隐式转换失败。SQL Server则会在UNION ALL时报类型不匹配。
实操避坑点：
- 所有字段在锚点里显式写出，包括
level、path、rn，别指望数据库自动推导 -
path统一用CAST(... AS VARCHAR(500))（SQL Server/MySQL）或TEXT（PostgreSQL），避免中间层因类型变窄丢数据 - MySQL中递归部分的
SELECT字段顺序必须和锚点逐列对应，连注释位置都不能错位 - PostgreSQL里可以用
WITH RECURSIVE ... LIMIT 100防死循环，但ROW_NUMBER()本身不参与终止逻辑，得靠WHERE r.level < 10手动截断
为什么不用多次LEFT JOIN代替递归CTE + ROW_NUMBER()
因为深度不确定时，硬写5层JOIN等于给自己埋雷：一改层级就得重写SQL；空层级字段全是NULL，后续处理要层层COALESCE；更麻烦的是，兄弟节点并列时，ROW_NUMBER()在多层JOIN里会按最终结果集排序，不是按每层独立编号，导致“第1个子节点的第2个孙子”这种语义完全丢失。
真实代价：
- 5层JOIN产生的中间结果集是指数级膨胀的，尤其当某节点有10个子、每个子又有10个孙，光第3层就产生1000行，而递归CTE逐层展开，内存可控
- 无法表达“只取每层前3个”的需求——
ROW_NUMBER() OVER (PARTITION BY level ORDER BY score DESC)在递归CTE里自然成立，在JOIN里得套5层子查询 - 索引失效风险高：JOIN条件常含
parent_id = ?或id IN (...)，优化器难走索引；递归CTE只要parent_id和id有索引，基本能命中
真正容易被忽略的，是路径拼接时字符集和排序规则的影响——比如SQL Server里数据库用Latin1_General_CI_AS，但path字段建成了Chinese_PRC_CI_AS，拼接过程不报错，但ORDER BY path结果会乱序，且很难排查。
