WITH RECURSIVE 是 MySQL 8.0+ 原生递归查询语法，非存储过程组件；因其语法结构严格（锚点与递归部分须用 UNION ALL 连接、CTE 名唯一）、执行模型冲突且不支持过程内动态拼接或参数绑定，故不可直接封装于存储过程中，应通过视图、客户端参数化查询或前置校验调用实现复用。
WITH RECURSIVE 是 MySQL 8.0+ 的原生语法，它不是存储过程的一部分，也不能在存储过程中“结合”使用——你不能把 WITH RECURSIVE 塞进 CREATE PROCEDURE 体里当普通 SQL 执行就完事。这不是写法问题，是执行模型冲突。
MySQL 存储过程不支持在内部动态构造并执行完整递归 CTE；更关键的是，WITH RECURSIVE 本身要求整个查询语句结构严格受控（比如锚点与递归部分必须用 UNION ALL 连接、CTE 名只能出现一次等），而存储过程的变量插值、拼接逻辑极易破坏这些约束，导致语法报错或行为不可控。
所以真实答案是：别在存储过程中封装 WITH RECURSIVE 查询。该查的时候直接写查询，需要复用就用视图或客户端参数化调用。
为什么不能把 WITH RECURSIVE 写进存储过程里
常见错误现象：ERROR 1064 (42000): You have an error in your SQL syntax，尤其在拼接 WHERE id = ? 或用 CONCAT 拼 CTE 名时爆掉。
-
WITH RECURSIVE必须是语句最外层结构，不能嵌套在INSERT ... SELECT、SELECT INTO或循环体内 - 存储过程里用
PREPARE/EXECUTE动态执行含WITH RECURSIVE的字符串，会触发权限限制（需EXECUTE+SQL_DYNAMIC权限），且无法绑定参数到 CTE 锚点 WHERE 条件中（?占位符在WITH子句里不生效） - 即使绕过语法检查强行执行，递归深度控制变量
cte_max_recursion_depth是会话级的——你在过程里SET SESSION，会影响后续所有查询，不是局部作用域
真要封装递归逻辑，该怎么做
正确做法是把参数化入口留在查询层，而非过程层。例如：
- 用视图模拟“半固定”递归：建一个带参数占位符的视图（虽然 MySQL 不支持参数化视图，但可用
CREATE VIEW v_tree AS WITH RECURSIVE ... SELECT * FROM cte配合外部WHERE过滤） - 客户端传参调用原生
WITH RECURSIVE：比如 Node.js 中用connection.query("WITH RECURSIVE ... WHERE id = ?", [rootId]) - 若必须用过程（如兼容旧版中间件），只让它返回根 ID，再由上层发起独立
WITH RECURSIVE查询——过程只做校验、权限检查、日志记录等前置动作
存储过程里硬要模拟递归？后果很现实
有人坚持用 WHILE + 临时表重写递归逻辑，结果发现：
- 每轮
INSERT INTO temp_table SELECT ... JOIN temp_table触发全表扫描，EXPLAIN显示type: ALL，索引完全失效 - 层级超过 5 层后，I/O 次数翻倍增长，
SHOW PROFILE能看到Creating sort index和Copying to tmp table占比飙升 - 并发调用时，多个连接同时写同名临时表（哪怕加了
CONNECTION_ID()后缀），仍可能因事务隔离级别导致幻读或死锁
真正棘手的永远不是“怎么写”，而是数据里藏着的环形引用、parent_id 类型不一致（INT 字段存了 ' '）、空值被当成有效节点参与 JOIN ——这些在 WITH RECURSIVE 中靠 WHERE cte.id IS NOT NULL 就能拦住，在存储过程里却得层层判空、去重、计数，越补越乱。
