深层递归慢或爆栈是执行模型问题：每层生成临时结果集致内存指数增长，索引常失效；应优先用固定层数 JOIN 扁平化、应用层循环或闭包表替代。
为什么 WITH RECURSIVE 一深就慢甚至爆栈
深层递归不是语法问题，是执行模型问题：每层递归都生成临时结果集，层数一多，内存占用指数增长，PostgreSQL 默认 work_mem 常常不够，MySQL 8.0 则可能直接报 Recursive query aborted after 1000 iterations。更隐蔽的是，索引在递归路径中往往失效——JOIN 条件落在递归引用列上时，优化器很难用上 B-tree 索引。
- 别依赖「查得出来」就等于「能上线」，5 层递归和 20 层的响应时间可能差两个数量级
- 如果层级深度可预估（比如组织架构最多 7 级、BOM 最多 5 层），优先用固定层数
LEFT JOIN扁平化 - 递归 CTE 中避免在
RECURSIVE部分写ORDER BY或聚合函数，会强制物化全部中间结果
用 JOIN 展开固定层级的树形结构
适用于已知最大深度（如部门树≤6 级、商品类目≤4 级）。核心思路是把「自关联 N 次」显式写出，用 COALESCE 或 CASE 合并路径字段，让查询走索引而非递归引擎。
SELECT d1.id AS level1_id, d1.name AS level1_name, d2.id AS level2_id, d2.name AS level2_name, d3.id AS level3_id, d3.name AS level3_name FROM departments d1 LEFT JOIN departments d2 ON d2.parent_id = d1.id LEFT JOIN departments d3 ON d3.parent_id = d2.id WHERE d1.parent_id IS NULL;- 确保
parent_id字段有索引，否则每次JOIN都是全表扫描 - 层级超过 4 层后 SQL 可维护性下降，此时应考虑应用层循环 + 缓存（如 Redis 存路径数组）
- MySQL 5.7 不支持 CTE，这种写法反而比模拟递归更稳定
用应用层循环替代数据库递归
当树深度不确定、但单节点子节点数有限（如评论回复、权限继承），数据库递归反而是瓶颈。把「找子节点」变成多次简单查询，由代码控制流程，更容易限流、加缓存、设超时。
- 第一次查根节点：
SELECT id, name FROM nodes WHERE parent_id IS NULL LIMIT 100 - 后续每次用上一批的
id批量查子节点：SELECT * FROM nodes WHERE parent_id IN (1,5,9,……) - 用
Map<Long, List<Node>>在内存里建父子映射，避免 N+1 查询 - Python 用
itertools.batched()（3.12+）或手动切片控制批量大小，防止IN列表过长触发 MySQL 的max_allowed_packet
用闭包表（Closure Table）彻底规避递归
如果树结构读多写少，且需要频繁查任意节点的全部祖先 / 后代，闭包表是比递归 CTE 更稳的选择——它把所有路径关系提前存成扁平记录，查询变成简单 WHERE。
CREATE TABLE node_closure (ancestor_id BIGINT NOT NULL, descendant_id BIGINT NOT NULL, depth INT NOT NULL, PRIMARY KEY (ancestor_id, descendant_id) );- 插入新节点时，需一次性插入「自己到所有祖先」+「所有子孙到自己」的新路径行，写开销大
- 查某节点所有后代只需：
SELECT n.* FROM nodes n INNER JOIN node_closure c ON n.id = c.descendant_id WHERE c.ancestor_id = 123 - PostgreSQL 可给
(ancestor_id, depth)加复合索引，加速「查第 N 层子节点」这类场景
递归查询真正的硬伤不在语法，而在它把本该由存储结构承担的路径关系，强行交给执行引擎实时推导。选哪种方案，取决于你更怕写入变慢，还是怕查询超时——这个权衡点，很容易被忽略。
