cte在存储过程中与普通查询中行为一致，但需注意变量作用域、执行上下文及语法位置限制；它不感知存储过程变量，必须紧接with定义且后跟单个dml语句，不可跨语句块或单独存在。
CTE在存储过程中和普通查询里行为一样吗
一样，但容易忽略变量作用域和执行上下文。CTE本身不感知存储过程的@variable，它只认当前SQL语句内可见的参数或变量；如果在CTE定义里引用了未声明或作用域外的@tenant_id，会直接报错Must declare the scalar variable "@tenant_id"。
常见错误现象：在存储过程里把CTE写在IF分支里，结果发现CTE没被识别——因为CTE必须紧跟在WITH之后、且只能出现在SELECT/INSERT/UPDATE/DELETE语句前，不能单独存在，也不能跨语句块。
- CTE必须是语句开头，前面不能有
SET、DECLARE、注释甚至空行（某些SQL Server版本严格校验） - 多个CTE用逗号分隔，最后一个不加逗号，否则报
syntax error near "," - CTE定义后必须紧接一个主DML语句，不能只定义不使用
怎么写CTE才不会拖慢存储过程性能
CTE不是缓存，它默认不物化。SQL Server 2022+支持MATERIALIZE提示，但老版本或MySQL 8.0仍靠优化器决定是否重复计算——同一CTE被引用两次，很可能扫表两次。
真正影响性能的是谓词位置：把高选择率过滤条件（如status = 'active'、tenant_id = @tenant_id）塞进CTE内部，比放在外层WHERE更安全；否则可能触发全表扫描再过滤。
- 避免在CTE里写
SELECT *，显式列出字段，减少内存和网络开销 - 别在CTE里用
ORDER BY（除非配合OFFSET/FETCH），SQL Server直接报错The ORDER BY clause is invalid in views, inline functions, derived tables, subqueries, and common table expressions - 如果某个CTE被多次引用且数据量大（比如>1万行），先
EXPLAIN看执行计划里有没有Spool或Compute Scalar，没有就考虑改用#temp_table
UNION ALL + CTE做集合运算时最常踩的坑
列对齐和去重逻辑最容易翻车。UNION要求所有分支列数、类型、顺序严格一致，否则报错all queries in a UNION must have the same number of columns；而UNION自动去重，代价高，日常应优先用UNION ALL。
典型场景是拼接不同业务线的订单数据，每个CTE分支都得保证输出结构统一：比如都带order_id、amount、source_type，不能有的漏source_type，有的用CAST(amount AS DECIMAL(18,2))，另一个用FLOAT。
- 每个CTE分支的
SELECT必须显式写出字段名，不能依赖*推导 -
UNION ALL前后分支的列名以第一个分支为准，后续分支别名无效 - 若需去重，放到最外层
SELECT DISTINCT或应用层处理，别让数据库反复排序
递归CTE在存储过程里怎么设终止条件才安全
递归CTE（WITH RECURSIVE）在存储过程中一旦失控，轻则超时，重则阻塞连接。关键不是“怎么写递归”，而是“怎么防死循环”。
PostgreSQL强制要求递归引用必须在UNION ALL右侧，SQL Server允许左侧但需确保锚点能收敛；MySQL 8.0则要求MAXRECURSION显式设置（默认100），超过即中断。
- 加层级计数器：
level INT DEFAULT 1，递归部分写level + 1 ，硬限制深度 - 检查父ID是否已出现过：用
NOT EXISTS (SELECT 1 FROM anchor WHERE id = recursive.parent_id)防环路 - 避免在递归部分用
NOW()、NEWID()等非确定性函数，否则优化器无法估算行数，可能拒绝执行
