mysql 8.0视图不支持顶层递归cte，因预编译阶段无法安全处理递归执行计划；可行方案包括封装为reads sql data存储函数调用，或用触发器维护预计算字段。
MySQL 8.0的WITH RECURSIVE是否支持视图定义
支持，但有硬性限制：递归CTE不能直接作为视图的顶层查询。你写 CREATE VIEW v AS WITH RECURSIVE ... SELECT ... 会报错 Recursive common table expression 'xxx' cannot be used in view。这不是语法写错了，是MySQL 8.0（包括8.0.33）明确禁止的——视图定义体里不允许出现递归CTE。
根本原因在于视图在预编译阶段无法安全处理递归执行计划，MySQL选择一刀切禁用。所以别试了，哪怕加了MAXRECURSION或改写成子查询嵌套也没用。
绕过限制的可行方案：用存储函数封装递归逻辑
把递归CTE封装进存储函数，再让视图调用它。虽然多一层间接，但能复用、可参数化，也符合SQL标准语义。
- 先创建函数
get_descendant_count，接收root_id，返回该节点下所有子孙数量（含自身） - 函数体内用
WITH RECURSIVE展开树，再COUNT(*)汇总 - 视图里调用它：
SELECT id, name, get_descendant_count(id) AS subtree_size FROM org_nodes
注意：函数必须声明为 READS SQL DATA，且不能在函数里做DML；如果层级过深（比如 > 1000），记得调大 cte_max_recursion_depth 系统变量，否则会中断并报错 Recursive query aborted after 1001 iterations。
替代视图的轻量方案：用预计算字段+触发器维护层级统计
如果实时性要求不高，或者树结构变更不频繁，比递归CTE更稳更快的做法是冗余一个统计字段，用触发器自动更新。
- 在原表加列
descendant_count INT DEFAULT 0 - 插入新节点时，触发器向上遍历父链，对每个祖先的
descendant_count+1 - 删除节点时，反向 -1；移动节点则先 -1 再 +1（需判断是否跨父）
这个方案查起来就是普通索引查询，毫秒级响应；缺点是触发器逻辑要覆盖所有树操作路径（INSERT/UPDATE/DELETE），且并发更新时需加行锁防竞态。不过比起每次查都跑一遍递归CTE，它在读多写少场景下优势明显。
调试递归CTE时最常见的三个坑
写递归CTE本身容易，但放到生产环境常卡在细节上：
-
UNION ALL必须写全，漏掉ALL会导致去重开销暴增，甚至死循环（因中间结果被误剪） - 锚点查询（anchor）和递归查询（recursive）的列数、类型、顺序必须严格一致，否则报错
Column count doesn't match或隐式转换出错 - 没设终止条件——比如递归JOIN没加
ON parent.id = child.parent_id，或JOIN条件恒真，就会无限生成行，直到达到cte_max_recursion_depth限制
真正麻烦的是第三种：错误不报语法问题，只在执行时缓慢卡住或突然中断，得靠 EXPLAIN FORMAT=TREE 看执行计划里有没有异常的“Recursive”节点膨胀。
