sql server 中索引视图的维护开销发生在基表 dml 时而非查询时，需通过 sys.dm_db_index_usage_stats 的 user_updates/system_updates 和 extended events 定位写入放大与阻塞。
SQL Server 中没有原生的“物化视图”概念，你实际在用的是 索引视图（Indexed View）——它通过唯一聚集索引将视图结果物理存储，但维护成本藏在基表变更时，而非查询时。
为什么不能只看 SELECT 执行计划？
索引视图的性能优势只体现在查询侧；而它的维护开销完全发生在基表发生 INSERT/UPDATE/DELETE 时。这些操作会同步更新索引视图的聚集索引，但这个过程不会出现在 SELECT 的执行计划里，也不会被 SET STATISTICS IO ON 捕获。
- 你看到的
SELECT * FROM my_indexed_view计划再干净，也不能说明写入压力小 - 基表每改一行，索引视图可能要多写几行（尤其含聚合、JOIN 时），且锁粒度可能升级
- 若视图定义含
COUNT_BIG(*)、SUM或多表JOIN，维护代价呈指数增长
查 sys.dm_db_index_usage_stats 看写入放大
这是最直接反映维护成本的 DMV：它记录每个索引的用户/系统级读写次数。对索引视图的聚集索引，重点关注 user_updates 和 system_updates 字段。
-
user_updates是基表 DML 触发的索引视图更新次数 —— 若它远高于基表自身 DML 频次（比如基表每天 1k 行变更，该值却达 5w），说明视图逻辑太重 -
system_updates高通常意味着统计信息自动更新频繁，间接反映索引视图数据分布剧烈变化 - 务必用
object_id关联到sys.indexes，确认你查的是视图的聚集索引，不是基表的其他索引
抓长时间运行的基表 DML 操作
索引视图维护是同步阻塞的。当基表写入变慢，第一怀疑对象就是索引视图。用以下方式定位：
- 开启
Extended Events捕获sql_batch_completed，筛选duration > 5000（5 秒）且语句含基表名，然后检查其执行计划中是否出现Index Insert/Index Update节点指向你的索引视图 - 查
sys.dm_exec_requests中wait_type为LCK_M_X或PAGELATCH_EX的会话，结合blocking_session_id追溯源头 - 避免依赖
sp_who2：它不显示索引视图维护引发的锁等待细节
刷新不是问题，但“不可刷新”才是陷阱
索引视图不需要手动刷新（不像 PostgreSQL 的 REFRESH MATERIALIZED VIEW），它的数据始终与基表强一致。但这也意味着：一旦创建，你就无法暂停维护——哪怕业务低峰期，基表写入仍会触发同步更新。如果某天发现基表 DML 延迟突增，而你又没在建视图前评估过写入负载，这时候删掉索引视图比优化它更快。
