MySQL 8.0 递归CTE必须显式使用WITH RECURSIVE，因解析器仅在此声明下才允许自引用；UNION ALL为强制要求，字段定义（含别名、类型、顺序）须完全一致，终止依赖结果集为空而非层数限制。
MySQL 8.0 的 CTE 不是“支持递归查询”，而是只允许用 WITH RECURSIVE 才能写递归逻辑——漏掉 RECURSIVE 关键字，哪怕语法全对，也会直接报错。
为什么必须写 WITH RECURSIVE，不能只写 WITH
MySQL 解析器对递归做了硬性作用域隔离：只有显式声明 RECURSIVE，才允许在递归部分（即 UNION ALL 后面的 SELECT）里引用自身 CTE 名。否则会报 Unknown table 'cte_name' 或更迷惑的 ERROR 1248 (42000): Every derived table must have its own alias——因为此时它把 CTE 当成普通子查询处理，根本没开放自引用权限。
常见踩坑点：
- 从 PostgreSQL 或 SQL Server 复制语句过来，顺手删掉了
RECURSIVE（它们部分版本可省略） - IDE 补全只提示
WITH cte AS，没带RECURSIVE，手敲时遗漏 - 文档截图截掉了关键字，照着抄就崩
UNION ALL 是强制要求，不是风格偏好
锚成员（初始查询）和递归成员之间必须用 UNION ALL，不能用 UNION。原因很实际：
-
UNION会触发跨轮次去重，而 MySQL 递归执行模型是按轮迭代（R0 → R1 → R2…），每轮输出天然不重叠（比如父 ID 和子 ID 不同），去重纯属冗余 - 去重需临时排序+合并，深度 >10 层时响应明显变卡；深度 >1000 轮时大概率触发
ERROR 3638 (HY000): Recursive query aborted after 1001 iterations - 官方明确建议：“Always prefer
UNION ALLin recursive CTEs”
字段定义必须严格一致，连别名都不能松动
锚成员和递归成员的 SELECT 列数、顺序、数据类型、甚至别名，必须一模一样。否则轻则报 ERROR 1252 (42000): Duplicate column name，重则因隐式转换失败导致 Truncated incorrect DOUBLE value。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
实操要点：
- 绝不用
SELECT *——表结构加字段，递归立刻失效 - 层级计数字段如
level必须在锚成员里初始化（如1 AS level），递归成员里写s.level + 1 AS level，漏AS就错 - 字符串字段若一边是常量（
'root'），一边是列（e.name），要确认两边字符集和排序规则一致，否则可能隐式转换告警
终止条件靠数据自然收敛，不是靠 WHERE 控制层数
MySQL 递归 CTE 没有类似 SQL Server 的 MAXRECURSION 参数。它只在某轮递归查询返回空结果集时自动停止——也就是说，终止完全依赖 JOIN 条件是否还能匹配出新行。
但你可以用 WHERE 做安全兜底：
- 在递归成员里加
WHERE s.level ，防止意外形成环或过深树 - 这个
WHERE是过滤本轮输入，不是控制总轮次；真正限制总轮次的是系统变量cte_max_recursion_depth（默认 1000） - 注意：递归成员里禁止
GROUP BY、ORDER BY、LIMIT、窗口函数——这些会直接报错，破坏迭代模型
最易被忽略的一点：递归不是“对每一行单独跑一次”，而是“每轮拿上一轮全部输出去 JOIN”。如果锚点返回 3 行，第一轮可能产出 12 行；第二轮就用这 12 行去驱动，不是只用新增的那几行。理解这点，才能预估真实扫描量和索引压力。
