递归cte不可封装进存储过程，因其不支持参数化重用，会导致执行计划黑盒化与调试困难；应优化cte本身：确保锚点走主键索引、join字段类型一致、加level限制、避免select*和中间排序，并优先考虑物化路径等替代方案。
别在存储过程中封装递归 CTE——它不支持参数化重用，强行塞进去只会让执行计划变黑盒、调试变困难。
WITH RECURSIVE 不能直接放进存储过程体里
MySQL 和 PostgreSQL 都明确禁止在存储过程的 BEGIN...END 块中定义可被多次调用的递归 CTE。你写的 WITH RECURSIVE 只能作为单条 SELECT 的一部分存在，无法像变量一样传参或复用。
- 常见错误：MySQL 报
ERROR 1356 (HY000): View 'xxx' references invalid table(s)，其实是把 CTE 误当成视图引用了 - PostgreSQL 报
ERROR: invalid reference to FROM-clause entry，因为递归别名（如org_hierarchy）在存储过程作用域内不可见 - 有人用
PREPARE+EXECUTE拼接 SQL，结果每次执行都重新解析、无法缓存执行计划
真正该优化的是 CTE 本身，不是包装方式
递归慢，90% 不是语法写错，而是索引没对齐或数据模型有坑。盯住 EXPLAIN ANALYZE 输出里的 “Recursive Union” 节点：
- 锚点查询（如
WHERE id = ?）必须走主键或唯一索引；否则第一层就全表扫描 - 递归成员的 JOIN 条件字段（如
e.parent_id = dt.id）两边类型必须一致；INT对VARCHAR会跳过索引 - 加
level字段并限制深度：WHERE dt.level ，比靠数据库自动终止更可控 - 递归分支里避免
SELECT *或ORDER BY；只选必要字段，排序留到最终主查询
需要“存储过程式调用”时的替代方案
不是硬塞递归进存储过程，而是让存储过程只做参数校验和调度：
- 在 PostgreSQL 中，把核心逻辑写成带参数的
VIEW（如CREATE VIEW dept_tree_for(id INT) AS WITH RECURSIVE ...），再在存储过程中SELECT * FROM dept_tree_for(2) - 在 MySQL 中，用
PREPARE stmt FROM ...预编译含WITH RECURSIVE的语句，存储过程中EXECUTE stmt USING @dept_id - 如果层级稳定，优先建物化路径字段（如
path VARCHAR(1000)），再配CREATE INDEX idx_org_path ON organization(path)；查询变成WHERE path LIKE '/2/%'
最易被忽略的一点：当你发现递归 CTE 的执行计划里，“Recursive Union” 下的实际行数远超预期（比如锚点返回 1 行，第一轮递归却扫了 5000 行），说明索引根本没生效——这时候改存储过程毫无意义，得回去盯 EXPLAIN ANALYZE 里的索引扫描行数。
