CTE不能复用，其作用域仅限于紧邻的下一个SQL语句；需复用时应选用视图、内联表值函数或临时表。
CTE能复用吗？别被WITH骗了
不能。SQL Server（以及PostgreSQL、MySQL 8.0+）里，WITH定义的CTE只在紧邻的下一个语句中有效，写一次就失效。很多人以为把常用逻辑提成CTE就能“一处修改、多处生效”，结果发现第二个SELECT里直接报错Invalid object name 'xxx'——因为CTE生命周期仅限单条语句。
实操建议：
- 如果多个查询都要用同一段逻辑，且数据量不大、计算不重，老老实实每个地方都写一遍CTE，或改用视图（
CREATE VIEW） - 若逻辑复杂又需复用，优先考虑内联表值函数（
CREATE FUNCTION ... RETURNS TABLE），它支持参数、可被多次引用 - 临时表（
#temp_table）适合中间结果大、后续要反复JOIN或过滤的场景，但要注意显式清理和作用域
什么时候该用内联TVF而不是CTE
当你发现存储过程中有3个以上查询都包含几乎一样的JOIN + WHERE + CASE逻辑块，而且每次只差一两个参数（比如@start_date、@status_filter），这时候CTE已经不够用了。
内联TVF本质是参数化视图，SQL Server会把它内联展开，不产生额外执行开销。而CTE只是语法糖，无法传参。
示例对比：
CREATE FUNCTION dbo.GetActiveOrders(@as_of DATE) RETURNS TABLE AS RETURN ( SELECT o.order_id, o.amount, c.name FROM orders o JOIN customers c ON o.cust_id = c.id WHERE o.status = 'active' AND o.created_date <= @as_of );
然后在存储过程里直接用：SELECT * FROM dbo.GetActiveOrders(@run_date)，还能在WHERE后加条件、和别的表JOIN，完全透明。
临时表 vs CTE：性能和可读性怎么权衡
CTE看着清爽，但SQL Server优化器对它的估算常不准，尤其嵌套深或涉及聚合时，容易选错执行计划；临时表虽然多写几行（CREATE TABLE #t、INSERT INTO #t、DROP TABLE #t），但它有统计信息、能建索引、执行计划稳定。
判断依据看这三点：
- 中间结果行数预估 > 10万？上
#temp_table，顺手加个CREATE INDEX IX_#t_order_id ON #t(order_id) - 后续要多次读取（比如先查总数，再分页，再按状态GROUP BY）？必须用临时表，CTE做不到
- 只是为让主查询更易读（比如把复杂的日期计算单独拎出来），且数据量小、无重复引用，用CTE更轻量
WITH RECURSIVE不是通用解药
有人看到“CTE能递归”就想拿它解决所有层级问题，比如组织架构、BOM展开。但递归CTE默认最多100层（MAXRECURSION 100），超了直接报错The statement terminated. The maximum recursion 100 has been exhausted，而且性能随深度指数增长。
真实业务中，如果层级不确定或可能很深（比如分销链路5级以上、审批流嵌套），别硬扛：
- 提前在应用层控制最大递归深度，或改用自连接（固定层级）+ UNION ALL
- 把树形结构扁平化存到辅助表（
path字段或lft/rgt），查起来快得多 - SQL Server 2017+ 可考虑
HIERARCHYID类型，原生支持路径比较和子树查询
真正省事的复用，不是靠语法缩写，而是把稳定逻辑沉淀成可参数化、可索引、可测试的数据库对象。CTE只是表达工具，不是架构组件。
