MySQL 8.0+才支持WITH RECURSIVE，5.7及更早版本直接报语法错误；其迭代执行模型适合树形遍历，需锚定成员、UNION ALL、正确JOIN条件及索引优化，MATERIALIZED提示可提升多层JOIN性能。
MySQL 8.0 才真正支持 WITH RECURSIVE
MySQL 5.7 及更早版本压根不识别 WITH RECURSIVE 语法，执行会直接报错：You have an error in your SQL syntax。这不是“表现优劣”问题，而是有无功能的问题。只有升级到 MySQL 8.0+，WITH RECURSIVE 才能被解析和执行。版本验证只需运行：SELECT VERSION();，结果低于 8.0.0 就必须升级。
WITH RECURSIVE 的执行模型天然适合树形遍历
MySQL 8.0 对递归 CTE 的实现是迭代式执行：先跑锚定成员（SELECT ... WHERE id = X）拿到初始行集，再反复用递归成员（JOIN 自身）生成下一层结果，直到无新行返回。这个过程不依赖应用层循环，也不需要临时表或存储过程，避免了多次网络往返和状态维护开销。
- 锚定成员必须返回至少一行，否则整个递归结果为空
- 递归成员中
JOIN条件必须引用上一轮结果（如e.manager_id = s.id），否则会变成笛卡尔积 - 必须用
UNION ALL，不能用UNION——后者去重会意外截断同名但不同 ID 的节点 - 没有显式终止条件时，MySQL 会靠内部迭代计数器兜底（默认
cte_max_recursion_depth = 1000），超限报错：Recursive query aborted after 1000 iterations
物化（MATERIALIZED）提示可显著改善多层 JOIN 场景性能
默认情况下，MySQL 8.0 会将 CTE 内联展开（类似子查询），但在递归深度 ≥ 5 且主查询含复杂关联时，重复计算成本陡增。此时可加 MATERIALIZED 提示强制物化中间结果：
WITH RECURSIVE subordinates AS ( SELECT id, name, manager_id, 1 AS depth FROM employees WHERE id = 1001 UNION ALL SELECT e.id, e.name, e.manager_id, s.depth + 1 FROM employees e INNER JOIN subordinates s ON e.manager_id = s.id ) SELECT * FROM subordinates s JOIN departments d ON s.id = d.employee_id JOIN locations l ON d.loc_id = l.id;
若在 WITH 后加上 MATERIALIZED（MySQL 8.0.22+ 支持），优化器会把 subordinates 结果存为临时表，避免在后续 JOIN 中反复执行递归逻辑。实测 6 层嵌套下响应时间可缩短 25%–35%。
索引缺失是递归查询慢的最常见原因
递归成员本质是反复做 JOIN，每次迭代都在查子节点。如果 manager_id 字段没索引，每轮都要全表扫描——10 层深度就等于扫 10 次全表。这是比语法、版本、提示都更致命的实际瓶颈。
- 必须确保递归字段（如
manager_id或parent_id）上有单列索引或作为联合索引的前导列 - 若查询常按层级排序（
ORDER BY depth），考虑覆盖索引：INDEX (manager_id, id, name, level) -
EXPLAIN FORMAT=TREE能清晰看到递归步骤是否走了索引；若出现Using temporary; Using filesort，基本就是索引没建对
递归查询快不快，80% 取决于这一条索引有没有、建得准不准。语法再新，没索引也白搭。
