递归查询性能差主因是层级控制不当、索引缺失或模型未对齐；应限制深度、建联合索引、用物化路径替代、检查执行计划并更新统计信息。
递归查询性能差，往往不是因为用了 WITH RECURSIVE，而是层级控制不当、索引缺失或数据模型没对齐递归路径。
限制递归深度，避免爆炸式展开
无约束的递归容易触发全树遍历，尤其当存在环状引用或深层组织结构（如100级部门嵌套）时，行数可能呈指数增长。PostgreSQL 和 MySQL 8.0+ 都支持显式深度限制：
- PostgreSQL：用
SEARCH DEPTH FIRST BY id SET orderkey+LIMIT控制输出；更稳妥的是在递归 CTE 的WHERE子句中加层级计数判断，例如level - MySQL：必须在递归成员中显式维护层级字段，并在
WHERE中拦截，如WHERE level ；否则默认只允许 1000 层，超限直接报错 - 业务上建议预估最大合理深度（如“最多查5级下属”），写死限制比依赖异常终止更可控
为递归字段组合建高效索引
递归查询通常基于父子关系字段（如 parent_id → id），但单列索引效果有限。关键是要让数据库能快速定位某节点的所有子节点或父节点：
- 若常查“某个 parent_id 的所有直接子项”，建
(parent_id, id)联合索引——覆盖查询条件 + 主键，避免回表 - 若需向上追溯祖链（如查某员工所属全部部门），建
(id, parent_id)索引，方便从叶子节点逐层找父节点 - 避免在递归字段上使用函数或表达式（如
COALESCE(parent_id, 0)），会导致索引失效
用物化路径替代深度递归（适合读多写少）
当层级稳定、变更不频繁（如类目树、行政区划），可冗余存储路径字符串（如 /1/5/12/），把递归转为前缀匹配：
- 查询某节点下所有后代：
WHERE path LIKE '/1/5/%'，配合path字段上的 B-tree 索引即可高效执行 - 插入/更新需额外维护路径字段，可用触发器或应用层保证一致性
- 相比纯递归，响应时间从 O(n) 降为 O(log n)，且不受数据库递归栈限制
检查执行计划，确认是否走索引
即使建了索引，递归 CTE 也可能因统计信息不准或谓词写法问题退化为顺序扫描：
- 用
EXPLAIN (ANALYZE, BUFFERS)查看递归部分是否命中索引，重点关注 “Index Scan on xxx” 行和实际行数是否接近预期 - 确保递归锚点（anchor member）和递归成员（recursive member）的连接字段类型一致（如都是
INT，而非INTvsVARCHAR），否则隐式转换会跳过索引 - 定期运行
ANALYZE table_name更新统计信息，尤其在大批量导入后
