MySQL存储过程中不能使用WITH RECURSIVE，因其仅支持顶层独立语句，不允嵌入BEGIN...END块；正确做法是改用视图封装递归CTE或在应用层执行。
WITH RECURSIVE 不能在 MySQL 存储过程中直接用作递归逻辑的“替代游标”——它根本就不能出现在存储过程体里。MySQL 不允许在 CREATE PROCEDURE 或 CREATE FUNCTION 的 SQL 语句块中使用 WITH RECURSIVE。
这不是语法疏漏，而是明确限制：递归 CTE 只能在顶层 SELECT/INSERT/UPDATE/DELETE 语句中使用，不支持嵌套在过程式代码中。
所以如果你正试图写一个存储过程，里面用 WITH RECURSIVE 一层层查子节点、再用 FETCH 处理每一行——这条路从一开始就是不通的。
为什么存储过程里不能写 WITH RECURSIVE？
MySQL 解析器在编译存储过程时，会将其中的 SQL 语句预编译为固定执行计划；而 WITH RECURSIVE 的执行依赖运行期动态迭代轮次（每轮输入是上轮全部输出），这与过程体的静态控制流模型冲突。
- 你尝试在
BEGIN ... END块里写WITH RECURSIVE，会直接报错：ERROR 1064 (42000): You have an error in your SQL syntax - 即使把 CTE 拆成临时表 + 循环模拟，也退化回传统方案，失去 CTE 的内存迭代和索引优势
- 官方文档明确列出：CTE 支持范围仅限于“standalone statement”，不包括存储过程、函数、触发器或事件中的语句
真正可行的替代路径：把递归逻辑提到应用层或视图层
别在存储过程里硬塞递归逻辑。正确做法是让存储过程只做参数封装和事务控制，把树形查询交给外部调用方或视图：
- 用
CREATE VIEW包一层WITH RECURSIVE，然后在存储过程中SELECT * FROM my_tree_view WHERE root_id = ? - 在应用代码（Java/Python/Go）里拼接并执行完整递归 SQL，避免过程内多轮 round-trip
- 如果必须复用逻辑，定义一个带参数的 prepared statement，而非存储过程
游标真有必要吗？多数场景其实不需要
你之所以想用游标，大概率是因为误判了需求边界：
- 要生成完整子树列表 → 直接
SELECT递归 CTE，一行返回全部结果 - 要逐级做权限校验 → 改用
EXISTS (WITH RECURSIVE ...)子查询，无需游标遍历 - 要更新整棵子树状态 → 用
UPDATE ... JOIN (WITH RECURSIVE ...)，MySQL 8.0 支持 CTE 参与 UPDATE/DELETE - 只有极少数情况（如需中间状态写日志、跨库分发）才真需要游标，但这时 CTE 本就不适用
最常被忽略的一点：递归 CTE 的终止条件完全由数据驱动，不是靠循环计数器。一旦表里存在父子自环（parent_id = id），哪怕你没写游标，WITH RECURSIVE 也会卡在第 1001 轮报错 —— 这种数据问题，在存储过程里用游标也拦不住。
