mysql 8.0 存储过程不能复用cte，只能将完整with recursive查询封装其中；正确做法是用in参数驱动锚点，前置拼接路径，显式终止递归，并用order by level desc limit 1取最长路径。
MySQL 8.0 中存储过程本身不能直接“结合” CTE 递归实现路径查找——因为 CTE（包括 WITH RECURSIVE）只能在单条 SELECT/INSERT/UPDATE/DELETE 语句中定义，不能跨语句复用，更不能在存储过程中“声明一次、多次调用”。你真正能做的，是把完整的递归路径查询逻辑封装进存储过程的 SELECT 语句里，然后通过参数控制起点。
为什么不能在存储过程中“先定义CTE再反复用”
CTE 的生命周期严格绑定于它所在的那一条 SQL 语句。哪怕你在存储过程中写：
WITH RECURSIVE path_cte AS (...) SELECT ... FROM path_cte;
这个 path_cte 在该 SELECT 执行完后就彻底消失，后续任何语句都无法引用它。试图在 INSERT INTO tmp SELECT ... FROM path_cte 或第二次 SELECT 中再次使用，会报错 Unknown table 'path_cte'。
所以所谓“结合”，其实是把整条带 WITH RECURSIVE 的查询塞进存储过程体，作为其核心执行语句。
正确做法：用 IN 参数驱动递归 CTE 的锚点
以查某节点向上到根的完整路径（如 "手机数码 > 手机 > 功能机 > 旧款功能机"）为例，存储过程只需接收一个 IN start_id INT，然后在内部构造递归查询：
-
WITH RECURSIVE的锚点部分用WHERE id = start_id定位起始节点 - 递归部分用
JOIN ... ON t.id = p.parent_id向上追溯（注意方向：父节点的id是子节点的parent_id，所以要反着连） - 用
CONCAT或GROUP_CONCAT拼接路径，推荐在递归中逐层前置拼接（避免最后排序混乱） - 必须加
WHERE p.parent_id != 0或WHERE p.parent_id IS NOT NULL作为显式终止条件，防止无限循环（尤其当数据有环或parent_id错误指向自身时）
典型错误：路径顺序颠倒或层级错乱
常见翻车点集中在路径拼接逻辑：
- 如果写成
CONCAT(p.path, ' > ', t.name)（后置拼），最终结果是“旧款功能机 > 功能机 > 手机 > 手机数码”，和业务要求的“从根到叶”相反 - 正确应为
CONCAT(t.name, ' > ', p.path)（前置拼），锚点初始化path = name，递归中父节点名永远加在左边 - 没加
ORDER BY LENGTH(path) DESC或按level排序，导致返回多行中间结果，而非最终完整路径 - 忘记给
parent_id字段建索引，递归每轮都要全表扫描，10 层深可能触发超时
完整可运行示例（查向上路径）
假设表结构为 category(id, name, parent_id)，parent_id = 0 表示根：
DELIMITER //
CREATE PROCEDURE GetCategoryPath(IN start_id INT)
BEGIN
WITH RECURSIVE path_cte AS (
-- 锚点：从指定节点开始
SELECT id, name, parent_id, name AS path, 1 AS level
FROM category
WHERE id = start_id
UNION ALL
-- 递归：找父节点，路径前置拼接
SELECT c.id, c.name, c.parent_id, CONCAT(c.name, ' > ', p.path), p.level + 1
FROM category c
INNER JOIN path_cte p ON c.id = p.parent_id
WHERE c.parent_id != 0 -- 显式终止：到根为止
)
SELECT path FROM path_cte ORDER BY level DESC LIMIT 1;
END //
DELIMITER ;
调用：CALL GetCategoryPath(9); → 返回 "手机数码 > 手机 > 功能机 > 旧款功能机"。
关键细节：最后一行 LIMIT 1 和 ORDER BY level DESC 确保只取最顶层（最长）路径；WHERE c.parent_id != 0 防止递归越过根节点继续查出无效行。
真正容易被忽略的是终止条件的双重保障——既要靠 WHERE 过滤掉无父节点的记录，也要依赖 MySQL 内部“无新行生成即停止”的隐式机制；一旦数据异常（比如出现 parent_id 指向不存在的 id），仅靠隐式终止可能卡死，必须显式写死边界。
