cte递归查询突然oom是因为mysql 8.0在内存中维护不断增长的结果集缓存，深度过大、分支过多或中间结果膨胀会迅速耗尽tmp_table_size和max_heap_table_size；需通过explain检查using temporary、using filesort等迹象，并在where中用层级计数（如cte.level）主动截断。
CTE递归查询为什么突然OOM？
MySQL 8.0的递归CTE（WITH RECURSIVE）不是简单“多跑几遍SQL”，它会在内存中维护一个不断增长的结果集缓存，直到递归终止。一旦层级过深、分支过多或中间结果膨胀（比如一个父节点关联上千子节点），tmp_table_size和max_heap_table_size就会被迅速耗尽，触发Out of memory错误——这不是堆内存不足，而是临时表内存上限被突破。
看EXPLAIN是否已暴露问题
执行前务必加EXPLAIN FORMAT=TRADITIONAL，重点关注Extra列：
- 出现
Using temporary：说明递归过程无法走索引，被迫建内存临时表，是OOM前兆 - 出现
Using filesort：即使没OOM，也意味着ORDER BY在递归层里失控，可能拖慢甚至卡死 - 没有
Using index for group-by（哪怕没GROUP BY）：说明递归JOIN字段缺失索引，每次迭代都全表扫
特别注意：递归层里的JOIN条件字段（如parent_id = cte.id）必须有单独索引或作为联合索引最左前缀，否则每轮迭代都是全表扫描。
递归深度和结果集大小怎么控？
MySQL不提供MAXRECURSION这类SQL Server式的硬限制，得靠写法兜底：
- 在递归层
WHERE中显式加层级计数：cte.level （需在CTE字段列表里定义并初始化<code>level） - 避免
UNION ALL无条件合并：确保递归层WHERE能真正过滤掉终止数据，否则空结果也会参与合并，累积元数据开销 - 精简SELECT字段：递归CTE里别用
*，只选后续真要用的ID、name、level等，减少单行体积 - 用
LIMIT不能直接加在CTE里，但可在最终SELECT后加，防止应用层取回超大结果集
参数调大就能解决问题？
不能。盲目调高tmp_table_size和max_heap_table_size只是掩盖症状：
- 这两个值取较小者生效，必须设为相同值（如
536870912） - 设太高会导致并发查询争抢内存，单个递归查占用几百MB，10个并发就吃掉几GB
- 真正该优化的是递归路径本身：检查是否有环状引用（A→B→A）、是否漏了
WHERE过滤导致爆炸式分叉 - 如果递归结果集稳定超百万行，考虑改用应用层分页拉取+缓存树结构，而不是强求单次SQL完成
递归CTE的内存压力不在“深度”，而在“宽度”——某一层返回10万行，下一层再对这10万行各自JOIN出10行，瞬间就是百万级中间结果。这点最容易被忽略。
