WITH RECURSIVE是SQL标准中处理树形结构的唯一可靠方式，MySQL 8.0+、PostgreSQL、SQL Server和SQLite 3.8.3+均原生支持，取代了易出错的自连接等旧方案。
用 WITH RECURSIVE 构建树形视图是唯一可靠方式
MySQL 8.0+、PostgreSQL、SQL Server 和 SQLite 3.8.3+ 支持递归 CTE，这是实现自关联层级结构的正解。旧版 MySQL（WITH RECURSIVE，强行用自连接只能查固定层数，无法应对深度不确定的组织架构或分类目录。
关键点在于：递归查询必须包含两个部分——初始查询（锚点，即根节点）和递归查询（通过 JOIN 关联自身），且二者需用 UNION ALL 合并。漏掉 ALL 或写成 UNION 可能导致重复行被去重，破坏层级路径。
-
WITH RECURSIVE必须紧跟在SELECT前，不能加注释或空行隔开 - 递归引用的表别名必须与 CTE 名称一致（例如
tree AS ( ... )，递归部分必须JOIN tree ON ...） - 务必加入终止条件（如
level ），否则遇到循环引用（A→B→A）会无限执行直至超时或栈溢出
字段设计决定能否正确渲染缩进和排序
只查 id 和 parent_id 不够。要让前端或命令行直观呈现树状，需在递归过程中累积路径和层级深度。常见做法是维护 path（如 '/1/5/23'）和 level（整数，从 0 或 1 开始）。
注意 path 字段类型：若用 VARCHAR，长度必须足够容纳最长可能路径（比如 20 级 × 每 ID 占 10 字符 = 至少 200）；若用 TEXT，某些数据库（如 MySQL）在 ORDER BY path 时默认只比较前 1024 字节，导致排序错乱。
- 推荐用字符串拼接生成
path：CONCAT(t.path, '/', c.id)（MySQL）或t.path || '/' || c.id（PostgreSQL） -
level初始设为 0 或 1，递归中写t.level + 1，别漏掉t.前缀，否则报“列歧义” - 按
path排序可保证树形顺序；仅按level排序会导致同级节点乱序
避免父ID为NULL或0引发的逻辑断裂
真实业务中，根节点的 parent_id 可能是 NULL、0、-1，甚至空字符串。锚点查询若只写 WHERE parent_id IS NULL，会漏掉 parent_id = 0 的根节点；若写 WHERE parent_id = 0，又会漏掉 NULL 的。
更稳妥的方式是显式定义哪些值代表根：用 COALESCE(parent_id, 0) = 0 统一处理 NULL 和 0，或直接列出所有合法根标识：WHERE parent_id IN (NULL, 0, -1)（注意：MySQL 中 IN (NULL, 0) 无法匹配 NULL，得改用 parent_id IS NULL OR parent_id IN (0, -1)）。
- 测试时务必插入一条
parent_id为NULL的记录，再插一条parent_id = 0的，验证两者是否都被查出 - 如果业务约定根节点
parent_id永远为NULL，那就严格按此假设写，但要在注释里写明，避免后续有人误填 0
性能敏感场景下必须加索引和深度限制
一张 10 万行的菜单表，若树深平均 8 层，递归展开后结果集可能达百万行。没索引时，每次递归都要全表扫描 parent_id 字段，响应时间从毫秒级升至秒级。
必须确保 parent_id 字段有索引（单列 B-Tree 即可）。另外，即使业务上树深不会超 10，也应在递归 CTE 中硬编码 WHERE t.level ——数据库优化器不一定能自动推导终止条件，尤其当 <code>parent_id 存在大量 NULL 时。
- PostgreSQL 用户可额外建表达式索引：
CREATE INDEX idx_menu_parent_level ON menu (parent_id, level)加速递归跳转 - MySQL 8.0+ 若开启
cte_max_recursion_depth全局变量（默认 1000），仍建议在语句内加WHERE level ，双重保险 - 视图定义里不要省略
WHERE深度限制，否则下游应用SELECT * FROM tree_view可能意外触发全量展开
实际层级结构永远比示例复杂——循环引用、多根并存、动态权限过滤、跨库 ID 冲突……这些细节不会出现在语法文档里，但会在上线后第一个深夜报警里出现。
