普通视图不提升性能，反而可能拖慢查询，因其每次调用都需重执行底层SQL；嵌套深、含GROUP BY/DISTINCT/聚合时更易导致条件无法下推、索引失效和全表扫描。
视图本身不提升性能，反而可能拖慢查询——除非你明确控制它的物化、索引和调用方式。
普通视图为什么越用越慢
普通视图只是保存 SELECT 语句的“快捷方式”，每次查询都会展开并重执行底层 SQL。如果视图嵌套了 3 层、JOIN 了 5 张表、还带聚合，那调用它的查询实际等价于执行一个更复杂的语句，优化器可能无法有效下推条件或复用索引。
- 常见错误现象：
EXPLAIN显示视图展开后出现Seq Scan或多层嵌套Nested Loop，而直接查基表加索引就能走Index Scan - 使用场景：适合权限隔离、接口封装、简化常用查询逻辑，但不适合高频、大数据量、低延迟要求的报表查询
- 容易踩的坑：在 WHERE 中引用视图列时，误以为能走基表索引——其实优化器未必能把条件“下推”到视图定义里；尤其当视图含
GROUP BY、DISTINCT或标量子查询时，下推基本失效
物化视图是唯一能真正提速的“视图”
Oracle 和 PostgreSQL（通过 CREATE MATERIALIZED VIEW）支持物化视图，SQL Server 则靠索引视图（CREATE VIEW ... WITH SCHEMABINDING + 建唯一聚集索引）模拟类似效果。它们把结果固化成物理存储，查询直接读取预计算数据。
- 关键限制：
CREATE INDEXED VIEW要求必须用SCHEMABINDING，所有表名带dbo.，不能有*，不能含非确定性函数（如GETDATE()） - 刷新代价：Oracle 物化视图可设
ON COMMIT或定时刷新，但每次刷新会锁表或产生大量日志；PostgreSQL 的物化视图需手动REFRESH MATERIALIZED VIEW，无法自动同步 - 性能影响：首次创建和刷新耗时长，但后续查询可快 10–100 倍；注意它会占用额外磁盘空间，并让写操作（INSERT/UPDATE）间接变慢
替代方案：派生表 + 覆盖索引往往更可控
比起依赖视图机制，很多场景下用显式派生表（subquery in FROM）配合基表上的覆盖索引，反而更容易调试、更少隐式开销。
- 示例：原视图定义为
SELECT a.id, a.name, SUM(b.amount) FROM orders a JOIN payments b ON a.id = b.order_id GROUP BY a.id, a.name，调用方只查最近 7 天的数据 —— 这时不如直接写：SELECT id, name, total<br>FROM (<br> SELECT a.id, a.name, SUM(b.amount) AS total<br> FROM orders a<br> JOIN payments b ON a.id = b.order_id<br> WHERE a.created_date >= CURRENT_DATE - INTERVAL '7 days'<br> GROUP BY a.id, a.name<br>) AS derived
并确保orders(created_date, id, name)和payments(order_id, amount)有合适索引 - 优势：WHERE 条件可明确下推，执行计划清晰可见，避免视图元数据缓存导致的统计信息陈旧问题
- 风险点：手写派生表易重复，需靠代码层抽象或模板管理，不能像视图那样被 GRANT 权限复用
真正难的不是选视图还是表，而是判断“哪些查询值得固化”——这需要结合慢查询日志、执行频次、数据新鲜度容忍度来权衡。一个被每天调用 200 次、响应超 2 秒、且允许 5 分钟延迟的销售汇总查询，比一个每秒调用、必须实时反映库存的订单详情视图，更适合上物化方案。
