SQL Server索引视图未生效主因是查询未精确匹配视图定义，须显式引用视图名或启用ANSI_WARNINGS/ARITHABORT；MySQL视图无加速作用；PostgreSQL物化视图刷新卡顿需用CONCURRENTLY并建唯一索引。
SQL Server 里索引视图为什么没生效？
多数人建了带 WITH SCHEMABINDING 的视图、加了唯一聚集索引，却发现查询计划里压根没用它——根本原因是查询没有「精确匹配」视图定义。SQL Server 不会自动把 SELECT * FROM Orders JOIN Customers 重写成走索引视图，除非你显式引用视图名，或启用 SET ANSI_WARNINGS ON 和 SET ARITHABORT ON（后者在某些 ORM 连接字符串里默认关着）。
实操建议：
- 必须用
SELECT * FROM <view_name></view_name>直接查，不能靠 JOIN 拆解后“碰巧覆盖” - 视图定义里的表名必须带 schema（如
dbo.Orders），否则SCHEMABINDING创建失败 - 所有参与列不能是计算列（除非用
PERSISTED）、不能含GETDATE()或子查询 - 检查执行计划：看到
Index Seek/Scan对应的是视图的索引名，而不是底层表名
MySQL 视图能加速多表 JOIN 吗？
不能。MySQL 视图只是保存 SELECT 语句的“快捷方式”，每次查询都展开重算，不缓存结果也不预建索引。你建一个 CREATE VIEW order_detail AS SELECT o.id, c.name, p.title FROM orders o JOIN customers c ON o.cid = c.id JOIN products p ON o.pid = p.id，查它和直接写这个 JOIN 完全等价，甚至更慢——因为多了层解析开销。
实操建议：
- 想提速，优先在
orders.cid、orders.pid、customers.id、products.id上建普通索引 - 如果固定查询模式很重（比如总按
c.region+ 时间范围查），考虑冗余字段或物化中间表（用定时任务刷新） - 避免在视图里用
ORDER BY或LIMIT——它们在 MySQL 视图中无效，还会误导自己
PostgreSQL 物化视图刷新卡住怎么办？
REFRESH MATERIALIZED VIEW 默认加锁阻塞读写，大表刷新时整个业务可能卡死。尤其当源表有频繁 UPDATE，而物化视图又没建索引，刷新过程会长时间扫描全表。
实操建议：
- 加
CONCURRENTLY参数：REFRESH MATERIALIZED VIEW CONCURRENTLY mv_order_summary，但要求物化视图必须有唯一索引 - 刷新前先在物化视图上建好索引（比如
CREATE UNIQUE INDEX ON mv_order_summary (order_month)），否则CONCURRENTLY直接报错 - 别在高峰期跑全量刷新；用分区表+交换方案替代：新建分区物化视图，刷完再
ALTER TABLE ... ATTACH PARTITION
什么时候该放弃视图，直接改查询逻辑？
当你发现为了“套用”一个通用视图，不得不在外部加一堆 WHERE 过滤、COALESCE 处理 NULL、甚至再套一层子查询时，视图已经成了性能累赘。视图的价值是封装稳定、复用率高的逻辑，不是掩盖设计缺陷。
实操建议：
- 检查执行计划里是否出现
Compute Scalar或多层嵌套Nested Loops——这往往是视图强行拼接导致优化器失效 - 对比原始 JOIN 查询和视图查询的
EXPLAIN ANALYZE结果，看 rows_estimated 和 actual_time 差异是否超过 3 倍 - 如果业务只在某几个字段上过滤（如只查
status = 'shipped'），直接在底层表加对应组合索引，比绕一圈视图快得多
视图不是银弹，索引视图依赖严苛条件，物化视图要权衡刷新成本，而普通视图根本不存数据。真正省事的优化，往往藏在 WHERE 条件能不能走索引、JOIN 顺序合不合理这些地方——别让“用了视图”变成“不用再想怎么优化”的心理安慰。
