视图展开后执行计划与原表不同，因视图仅存select定义，数据库内联展开时可能破坏原表优化路径：group by/distinct阻碍where下推、多表join干扰连接顺序、非确定性函数禁用索引seek；with schemabinding可强化依赖、支持索引视图并排除抖动；判断是否折叠需查执行计划中compute scalar等节点及行数预估一致性；物化视图适用于逻辑固定、基表更新少、查询频繁场景，但需注意各数据库实现差异及物化表自身索引设计。
视图展开后执行计划为什么和原表完全不同
SQL 视图本身不存数据，只是保存了 SELECT 语句的定义。当查询视图时（比如 SELECT * FROM my_view），数据库会把视图定义“内联展开”到外层查询中，再生成执行计划。这个过程看似透明，但实际可能破坏原本对物理表优化过的访问路径。
常见破坏点包括：
- 视图里用了
GROUP BY或DISTINCT，导致外层查询无法下推WHERE条件，全表扫描不可避免 - 视图含多表
JOIN，而外层又加了新条件，优化器可能误判连接顺序或丢失索引提示 - 视图定义中用了子查询或标量函数（如
GETDATE()、ISNULL()），让谓词无法被索引 SEEK 捕获
为什么 WITH SCHEMABINDING 能改善视图性能
默认创建的视图没有绑定底层对象结构，SQL Server 在展开时必须做额外元数据检查，且禁止很多优化（比如索引视图前提）。加上 WITH SCHEMABINDING 后：
- 视图与基表列形成强依赖，优化器能更早确认列可空性、数据类型、是否允许 NULL —— 这直接影响 JOIN 策略选择
- 允许你后续在视图上建唯一聚集索引（即“索引视图”），真正物化结果，避免每次查询都重算
- 禁用某些非确定性函数（如
GETDATE()、NEWID()），从源头排除执行计划抖动风险
注意：SCHEMABINDING 要求所有引用对象必须用两段式名称（如 dbo.orders），且基表不能被 DROP 或改列名，否则视图失效。
如何判断视图是否被真正“折叠”进执行计划
别只看语句长得像，重点看执行计划里有没有出现 Compute Scalar、Concatenation 或大量 Table Spool —— 这些往往是展开失败、被迫分步计算的信号。
实操建议：
- 在 SSMS 中按
Ctrl+L查看估计执行计划，右键各节点 → “属性”，检查Defined Values和Output List是否包含视图内部列别名 - 对比
SELECT * FROM physical_table WHERE ...和SELECT * FROM my_view WHERE ...的Estimated Number of Rows是否一致；差一个数量级大概率没下推成功 - 用
SET STATISTICS XML ON抓执行计划 XML，搜索<relop. scalar></relop.>，存在即说明有表达式延迟求值
物化视图（或等效方案）什么时候值得上
如果你的视图逻辑固定、基表更新不频繁（比如每小时批量导入一次）、且查询频次高，硬上物化是性价比最高的解法。但注意不同数据库叫法和能力差异：
- SQL Server：用
CREATE VIEW ... WITH SCHEMABINDING+CREATE UNIQUE CLUSTERED INDEX实现索引视图（要求满足严格条件，如无MAX、TOP、浮动精度列） - PostgreSQL：没有原生物化视图，但可用
REFRESH MATERIALIZED VIEW CONCURRENTLY（v9.4+），配合定时任务或触发器同步 - MySQL：无内置支持，常用
INSERT INTO summary_table SELECT ...+ 定时事件模拟，需自行维护一致性
最容易被忽略的一点：物化后，WHERE 条件是否仍能走索引，取决于物化表本身的索引设计，而不是原视图定义 —— 别建完就以为万事大吉。
