MySQL 8.0的WITH RECURSIVE无法通过EXPLAIN或SHOW PROFILE查看每轮迭代中间结果，因其执行模型为黑盒式轮次追加，仅维护内部迭代计数器（cte_max_recursion_depth控制），不暴露R₀、R₁等轮次细节，且递归成员严禁GROUP BY、ORDER BY等破坏轮次隔离的操作。
MySQL 8.0 的 WITH RECURSIVE 不暴露每轮迭代的中间结果集，也没有内置视图或日志能直接“看到”内存中第 N 轮生成了哪些行——它不是调试器，而是按轮次追加到内部临时表的黑盒执行模型。
为什么无法用 EXPLAIN 或 SHOW PROFILE 查看每轮迭代
MySQL 的 EXPLAIN 只显示锚点查询和递归查询的执行计划骨架，不展开轮次；SHOW PROFILE 也只统计总耗时、临时表创建次数等聚合指标，无法区分 R₀、R₁、R₂……这是因为迭代过程发生在执行器内部，不生成用户可见的中间表或语句事件。
-
EXPLAIN FORMAT=TREE会把整个 CTE 当作一个节点，递归部分标为 “Recursive reference”，无细节 -
performance_schema中没有对应“CTE iteration counter”的事件表（如events_statements_history_long不记录每轮） - 开启 general_log 或 slow_query_log 仅记录完整 SQL 入口，不记录中间轮次
用 WHERE + level 控制并观察每轮输出的变通方法
虽然不能“追踪内存”，但可以强制让每轮结果显式分离，靠人工模拟迭代过程来反推行为。核心是：在递归成员中加入 level 计数，并用外部 WHERE 截断轮次。
- 先确保 CTE 定义里有层级计数，例如
1 AS level（锚点）、s.level + 1（递归） - 执行时不在 CTE 内部加
WHERE level ，而是在最终SELECT外层加：SELECT * FROM dept_tree WHERE level = 1;查第 0 轮+第 1 轮合并结果？不对——注意：锚点是 level=1，第一轮递归产出的是 level=2，所以WHERE level = 2实际就是第一轮新增行 - 逐轮执行：
SELECT * FROM dept_tree WHERE level = 1;→ 锚点；SELECT * FROM dept_tree WHERE level = 2;→ 第一轮 JOIN 结果；WHERE level = 3→ 第二轮……这样能验证每轮是否符合预期 JOIN 行为
cte_max_recursion_depth 是轮次计数器，不是行数限制
设置 SET SESSION cte_max_recursion_depth = 5; 后，若第 6 轮启动前触发中断，报错 Recursive query aborted after 5 iterations，说明 MySQL 确实维护了一个严格递增的轮次计数器，且该计数器独立于结果行数——哪怕某轮只产出 1 行，也算一次迭代。
- 这个变量可动态设，但仅对当前 session 生效；全局修改需
SET PERSIST cte_max_recursion_depth = 200; - 错误信息里的 “after 5 iterations” 指的是完成了 5 轮（R₀ 到 R₄），第 6 轮（R₅）被拒绝，不是“查了 5 行就停”
- 如果想确认某次查询实际跑了几轮，只能靠日志+轮次字段反推：比如最终结果中最大
level是 4，则共执行了 4 轮（R₀ 对应 level=1，R₃ 对应 level=4）
真正容易被忽略的陷阱：递归成员里不能出现任何破坏轮次隔离的操作
一旦在递归分支里写 GROUP BY、ORDER BY 或子查询引用 CTE 自身，MySQL 会直接报错，而不是静默降级——这不是兼容性问题，而是执行模型硬性约束。它要求“单轮输入 → 单轮输出”必须是确定性、无副作用的映射。
-
ORDER BY禁止：不是因为性能，而是排序会打乱“上轮全部输出作为本轮全部输入”的顺序假设 -
GROUP BY禁止：聚合会把多行压缩成一行，破坏“本轮输入行数决定下轮 JOIN 驱动行数”的基数逻辑 - 哪怕只是
SELECT ... FROM (SELECT * FROM subordinates) AS s这种包装，也会触发Recursive reference in a subquery is not allowed
