结论：存储过程里写递归查询不如单独用with recursive——cte不支持在存储过程中嵌套递归调用，强行封装会掩盖执行计划问题、增加调试成本；mysql和postgresql均不支持存储过程中参数化重用递归cte，易报错且无法复用执行计划；性能瓶颈多源于锚点未走索引、join字段类型不匹配或缺失层级限制。
直接说结论：存储过程里写递归查询，不如把 WITH RECURSIVE 拆出来单独用——CTE 本身不支持在存储过程中“嵌套递归调用”，强行封装进存储过程反而掩盖执行计划问题、增加调试成本。
为什么别在存储过程里封装递归 CTE
MySQL 和 PostgreSQL 都不允许在存储过程体中直接定义并多次调用递归 CTE；你写的 WITH RECURSIVE 只能作为单条语句的一部分存在，不能被变量化、参数化重用。常见错误现象包括：
-
ERROR 1356 (HY000): View 'xxx' references invalid table(s) or column(s)（MySQL 中误当视图引用） - PostgreSQL 报
ERROR: invalid reference to FROM-clause entry，因递归别名作用域受限 - 存储过程中用
PREPARE/EXECUTE拼接递归 SQL，结果每次执行都重新解析，无法复用执行计划
真正该优化的其实是 CTE 本身的写法
递归性能差，90% 不是语法问题，而是锚点和递归成员没对齐索引或数据模型。关键实操点：
- 锚点查询（
WHERE id = ?）必须走主键或唯一索引，否则第一层就全表扫描 - 递归成员的
JOIN条件字段（如e.manager_id = eh.id）两边类型必须一致，INT对VARCHAR会跳过索引 - 加
level并限制深度：WHERE eh.level ，比靠数据库自动终止更可靠 - 避免在递归分支里
SELECT *或ORDER BY，只选必要字段，排序留到最终主查询
当真需要“存储过程式调用”时怎么办
不是硬塞递归进存储过程，而是让存储过程只做参数校验 + 调用预编译好的递归查询：
- 把核心递归逻辑写成一个带参数的
VIEW（PostgreSQL）或PREPARE语句（MySQL），在存储过程中EXECUTE它 - 用
INOUT参数接收 ID，但递归主体仍用WITH RECURSIVE直接查，不拆进循环 - 如果层级关系稳定，优先建物化路径字段（如
path VARCHAR(1000)），再配CREATE INDEX idx_tab_path ON tab(path)，查询变成WHERE path LIKE '/123/%'
最易被忽略的一点：递归 CTE 的执行计划里，“Recursive Union”节点下的实际行数如果远超预期（比如锚点返回 1 行，第一轮递归却扫了 5000 行），说明索引没生效或连接条件写错了——这时候改存储过程毫无意义，得回去盯 EXPLAIN ANALYZE 输出里的索引扫描行数。
