MySQL 8.0强制要求使用WITH RECURSIVE，因解析器仅在此语法下允许CTE自引用；漏写RECURSIVE会导致“Unknown table”或“Recursive reference not allowed”报错，本质是作用域隔离机制。
必须用 WITH RECURSIVE，不能只写 WITH；否则递归部分会报错“Unknown table”或“Recursive reference not allowed”。
为什么 WITH RECURSIVE 是硬性要求
MySQL 8.0 对递归 CTE 做了显式语法隔离：只有加上 RECURSIVE 关键字，解析器才允许在递归成员中引用自身 CTE 名。漏掉它，哪怕逻辑完全正确，也会直接报错 ERROR 1248 (42000): Every derived table must have its own alias 或更迷惑的 Unknown table 'cte_name'——因为此时 CTE 被当作普通非递归表达式处理，作用域不包含递归体。
常见错误场景：
- 从 PostgreSQL 或 SQL Server 复制语句过来，直接删掉
RECURSIVE（它们部分版本可省略） - IDE 自动补全只提示
WITH，没带RECURSIVE - 文档里示例截图截掉了关键字，导致手敲遗漏
UNION ALL 不是可选项，是性能与正确性的双重保障
递归 CTE 的锚成员和递归成员之间必须用 UNION ALL 连接。用 UNION 会触发去重逻辑，而 MySQL 在递归执行过程中无法高效完成跨层级去重，轻则报错 ERROR 3638 (HY000): Recursive query aborted after 1001 iterations，重则查出重复数据或无限循环。
关键原因：
- 递归每层生成的结果天然不重叠（比如父 ID 和子 ID 不同），去重纯属冗余开销
-
UNION内部需临时排序+合并，大幅拖慢迭代速度，尤其在深度 >10 层时响应明显变卡 - MySQL 官方明确建议：“Always prefer
UNION ALLin recursive CTEs”
字段数量、类型、顺序必须严格一致
锚成员（初始查询）和递归成员（SELECT 部分）输出的列数、对应位置的数据类型、甚至别名都得一模一样。否则报错 ERROR 1252 (42000): Duplicate column name 或更隐蔽的 Truncated incorrect DOUBLE value（类型隐式转换失败）。
实操要点：
- 显式写出所有字段，别用
SELECT *—— 表结构一旦加字段，递归就崩 - 层级计数字段如
level必须在锚成员里初始化（如1 AS level），递归成员里写st.level + 1 AS level，不能漏AS别名 - 字符串字段若来自不同来源（比如锚成员是常量
'root'，递归成员是列e.name），确保两边字符集和排序规则一致，否则可能触发隐式转换警告
终止条件靠数据自然收敛，不是靠 WHERE 控制层数
MySQL 递归 CTE 没有类似 MAXRECURSION 的内置层数限制参数。它的终止完全依赖递归成员是否还能 JOIN 出新行。也就是说：只要 JOIN 条件还能匹配到未访问过的记录，就会继续迭代；一旦某轮结果为空，自动停止。
这意味着：
- 不能在递归成员里加
WHERE level 这类条件来“防死循环”——语法报错，<code>WHERE在递归分支中不被允许 - 真要防意外，得靠业务数据约束：比如确保
manager_id不指向自己、不存在双向父子关系、无环路径 - 调试时可在最终
SELECT加LIMIT 100观察前几层，但这是取结果的限制，不影响递归过程本身
最易被忽略的一点：递归结果集默认无序，ORDER BY 只能在最外层 SELECT 中使用。如果需要按树形顺序展示（如先根后子），必须额外加 path 字段拼接路径字符串，再按该字段排序——这点和 PostgreSQL 的 SEARCH DEPTH FIRST 机制完全不同，得手动模拟。
