CTE不能替代需多次扫描或索引加速的中间表，仅适合单次消费、逻辑清晰的临时结果；是否改用取决于#temp表使用次数、索引及JOIN/聚合情况，且WITH前必须加分号，谓词需下推至每个CTE，避免SELECT*，多次引用时SQL Server默认重算，物化需显式启用且不默认保证。
CTE 不能直接替代需要多次扫描或索引加速的中间表，但它能安全替换单次消费、逻辑清晰的临时结果。 是否值得改，取决于你那张 #temp 是不是只被用一次、有没有建索引、是否参与了多轮 JOIN 或聚合——不是语法上“能写”，而是执行计划里“真省事”。
WITH 前必须加分号，否则存储过程编译失败
SQL Server 和 PostgreSQL 都要求 WITH 必须是语句开头。如果前一条是 SET @var = ...、IF 块结尾、甚至空行或注释，不加分号就会报 Incorrect syntax near the keyword 'with'。
- 所有 CTE 定义前统一加
;，哪怕前面是空行或注释 - 检查
DECLARE、SET、PRINT等语句末尾是否带分号——DBeaver 或 SSMS 的自动补全不可靠 - 生产脚本必须显式写，别依赖工具“帮你补”
谓词必须下推到每个 CTE，否则可能全表扫描
CTE 不是物化视图，它不缓存数据，也不保留统计信息。外层 WHERE 条件不会自动下推到 CTE 内部，优化器很可能先算完整个 CTE 再过滤，导致索引失效。
- 比如想查
tenant_id = @tenant_id AND status = 'active'的订单，别只在外层WHERE过滤 - 每个 CTE 的子查询里都显式带上
WHERE tenant_id = @tenant_id - 避免在 CTE 中用
SELECT *，只取后续真正需要的列，减少数据搬运量
同一 CTE 被引用多次时，SQL Server 默认重算两次
CTE 不是临时表，没有物理存储。如果主查询中两次 JOIN 同一个 CTE，SQL Server 通常会分别执行两次底层查询，而不是复用结果——除非满足特定条件（如简单查询 + 优化器判定可重用）。
- 若 CTE 被引用 ≥2 次，且基表大、计算成本高，考虑改用带索引的
#temp表 -
OPTION (RECOMPILE)有时能帮优化器识别重复引用，但不保证物化，慎用于高频过程 - SQL Server 2022+ 支持物化 CTE（需显式启用），但默认关闭，生产环境别默认指望它
最容易被忽略的是：CTE 的“简化”只是逻辑层面的，它不改变执行本质。你看到的 WITH a AS (...), b AS (...) 只是给优化器多了一次重写机会，实际是否拆分、是否物化、是否走索引，全看执行计划里的 Compute Scalar、Table Spool 和实际 I/O。别一加 WITH 就以为变快了，先 EXPLAIN 或看实际执行计划再说。
