SQL Server 视图中WITH必须紧邻主SELECT且不可省略，字段须显式命名、避免SELECT*，CTE不物化、禁止递归、引用需按定义顺序。
SQL Server 视图里能直接用 WITH 子句，但必须放在 SELECT 主查询之前、且主查询不可省略——否则视图创建会失败。
WITH 必须紧邻主 SELECT，不能单独存在
很多人写完 WITH cleaned_orders AS (SELECT ...) 就结束，结果 CREATE VIEW 报错：“Incorrect syntax near 'WITH'”。这不是语法不支持，而是 SQL Server 要求 WITH 后必须紧跟一个完整的 DML 语句（SELECT / INSERT / UPDATE / DELETE），而视图定义只允许 SELECT 作为主体。
-
WITH不是独立语句，它只是主查询的“前置声明”，不是“可执行块” - 视图中写法必须是：
WITH cte1 AS (...), cte2 AS (...) SELECT ... FROM cte1 JOIN cte2 ... - 如果只想要中间结果集而不查出来，那不该建视图，该建临时表或表变量
- 常见翻车：把测试用的
WITH ... SELECT拿过来直接塞进CREATE VIEW ... AS，漏掉最后那个SELECT，就报错
字段名必须显式列出，别用 SELECT *
视图对字段名敏感，SELECT * 在 WITH 子句里等于埋雷。一旦基础表加字段或调换顺序，视图字段顺序、个数、类型全可能错位，下游应用查 col4 却拿到 updated_at 而不是预期的 status。
- 每个
WITH子句内部，所有字段必须用AS显式命名，比如ord_id AS ord_id或COALESCE(status, 'pending') AS ord_status - 跨表 JOIN 后，务必用表别名限定，避免
id冲突，例如o.id AS ord_id,u.id AS usr_id - 聚合字段要带动词前缀，如
COUNT(*) AS cnt_orders，和原始字段天然区隔 - MySQL 迁移来的 SQL 尤其危险：PostgreSQL 允许
SELECT *+ORDER BY 1，SQL Server 不认这种位置引用
多层 CTE 引用要按顺序定义，不能循环依赖
SQL Server 要求 CTE 定义顺序即引用顺序：后定义的可以引用前面的，但反过来不行。试图让 cte_a 引用尚未声明的 cte_b，会直接报错 Invalid object name 'cte_b'。
- 合理分层示例：
raw_orders AS (...)→enriched_orders AS (SELECT ... FROM raw_orders ...)→summary AS (SELECT COUNT(*) FROM enriched_orders GROUP BY ...) - 禁止写法：
summary AS (... FROM enriched_orders ...)放在enriched_orders前面 - 递归 CTE（
WITH RECURSIVE）在 SQL Server 中不支持，要用OPTION (MAXRECURSION n)配合自引用写法，且必须有终止条件 - 想复用逻辑但又不想严格串行？拆成两个独立视图，或者用内联函数封装计算逻辑
性能陷阱：SQL Server 默认不物化 CTE，重复引用 = 重复执行
和直觉相反，SQL Server 的 CTE 默认是“宏展开”——每次被 FROM 或 JOIN 引用，都会重新跑一遍子查询。如果某个 CTE 扫描千万级日志表，又被主查询引用三次，实际执行三次全表扫描。
- 验证方法：在 SSMS 中对视图执行
EXPLAIN（即显示估计执行计划），看相同扫描节点是否出现多次 - 缓解手段：给重计算 CTE 加
OPTION (RECOMPILE)，帮优化器生成更贴合参数的计划；或改用带索引的物理临时表 -
MATERIALIZED关键字在 SQL Server 中不存在（那是 PostgreSQL 的语法），别照搬 - 真正需要缓存中间结果时，优先考虑
SELECT ... INTO #temp+ 索引，而不是强求 CTE 物化
最常被忽略的点是数据边界处理：CTE 里 LEFT JOIN 后字段为 NULL，但视图外层没做 ISNULL 或 CASE 判空，业务代码直接取值就崩。逻辑拆得再清楚，也救不了没兜底的 NULL 传播。
