cte本身不提升性能，递归cte易因锚点无索引、on条件非sargable、缺层级限制或未剪枝导致全表扫描、膨胀或栈溢出；优化需聚焦锚点精准索引、sargable连接、层级控制及必要时改用临时表或闭包表。
CTE（Common table Expression）本身不直接提升性能，反而可能因重复计算或不当递归导致性能下降。关键不在“用不用CTE”，而在“怎么写”——尤其是递归CTE，稍有不慎就会触发全表扫描、多层嵌套膨胀甚至栈溢出。
递归CTE的性能陷阱在哪
递归CTE由锚点（anchor）和递归成员（recursive member）组成，执行时sql Server（或其他支持递归的数据库）会将两者反复合并迭代，直到无新行产生或达到最大递归深度。问题常出在：
- 锚点查询未走索引，导致每次迭代都扫描全表
- 递归谓词（ON条件）无法利用索引，例如使用函数包裹列：
ON t.parent_id = ISNULL(r.id, 0) - 未限制递归层级（
OPTION (MAXRECURSION n)缺失），深层树形结构引发大量中间结果 - 递归结果集未及时剪枝，比如子节点已超出业务范围仍继续向下展开
优化递归CTE的四个实操方向
不是删掉CTE，而是让递归更“聚焦”、更“可控”：
- 锚点务必精准+索引覆盖：锚点应只查顶层节点（如
WHERE parent_id IS NULL），且该字段需有索引；若涉及多条件，考虑联合索引覆盖全部过滤列 - 递归连接条件必须SARGable：避免在递归JOIN的ON子句中对字段做计算或类型转换；优先用
t.parent_id = r.id这类直连方式 - 提前终止 + 层级控制：用
LEVEL（或自定义序号列）记录当前深度，配合WHERE level 主动截断；同时加上<code>OPTION (MAXRECURSION 100)防失控 - 必要时拆解为循环或临时表：当树深大、分支广（如组织架构超千级）、且需多次引用中间结果时，用
#temp分层存入各层级数据，比纯递归更稳定可调
替代方案比一比：什么情况下不该硬扛递归CTE
不是所有树形场景都适合WITH递归：
- 仅需查某节点的直接子节点？→ 改用简单JOIN，别上CTE
- 要查路径（如“/A/B/C”）且层级固定≤3？→ 用LEFT JOIN自连接3次，性能通常更好
- 频繁查询任意节点的祖先链？→ 预计算
path字段（如/1/5/23/）并建全文索引或使用HIERARCHYID（SQL Server） - 数据变更频繁、树结构动态性强？→ 考虑闭包表（Closure Table）模式，用额外关系表存储所有祖先-后代对，查起来快，维护成本换查询效率
递归CTE是表达清晰的利器，但不是性能银弹。看清数据分布、索引现状和真实查询模式，再决定是调优、拆解，还是换模型——不复杂但容易忽略。