视图（View）是数据库中的一种虚拟表，它并不实际存储数据，而是基于一个 `SELECT` 查询语句动态生成的结果集
视图（View）是数据库中的一种虚拟表，它并不实际存储数据，而是基于一个SELECT查询语句动态生成的结果集。创建视图使用CREATE VIEW语句，其本质是将一条SELECT查询语句保存为一个命名对象，后续可像操作普通表一样查询该视图（支持SELECT，但对INSERT/UPDATE/DELETE有严格限制，取决于视图的定义是否可更新）。
✅ 基本语法：
CREATEVIEWview_nameASSELECTcolumn1,column2,...FROMtable_nameWHEREcondition;📌 特点：
- 虚拟性：不占用额外存储空间（除非是物化视图，如 PostgreSQL 的
MATERIALIZED VIEW或 Oracle 的物化视图，但标准 SQL 视图默认非物化）； - 简化复杂查询：封装多表连接、聚合、过滤等逻辑；
- 安全性：可限制用户仅访问视图中的特定列或行，实现数据访问控制；
- 逻辑独立性：底层表结构变化时，若视图定义兼容，应用层无需修改。
⚠️ 注意：
- 视图上执行
DML（增删改）通常要求：
• 单表来源；
• 不含聚合函数、DISTINCT、GROUP BY、HAVING、子查询（在SELECT列表或WHERE中的非简单子查询）等；
• 所有被修改列必须直接映射到基表列，且不可为表达式或常量。
示例：
CREATEVIEWactive_usersASSELECTid,username,emailFROMusersWHEREstatus='active';之后可直接查询：SELECT * FROM active_users;
视图（View）和物化视图（Materialized View）虽然都提供“虚拟表”式的逻辑抽象，但核心区别在于数据是否物理存储与是否自动刷新：
| 维度 | 普通视图（View） | 物化视图（Materialized View） |
|---|---|---|
| 存储方式 | ❌ 不存储数据；仅保存SELECT查询定义（元数据） | ✅物理存储查询结果（一张实际的数据表） |
| 数据实时性 | ✅ 实时：每次查询都执行底层 SQL，返回最新数据 | ⚠️ 延迟：数据是快照，需手动或定时刷新（如REFRESH MATERIALIZED VIEW） |
| 查询性能 | 可能较慢（尤其涉及多表连接、聚合、大数据量时，每次重算） | ✅ 通常更快（直接查预计算结果，支持索引、分区等优化） |
| 更新能力 | 大部分数据库中不可直接 DML（除非简单单表可更新视图） | 一般只读（PostgreSQL 默认不可写；Oracle 可配置可更新，但需满足严格条件） |
| 存储开销 | 极低（仅 SQL 文本） | 较高（占用磁盘空间，且需维护冗余数据） |
| 标准支持 | ✅ 所有主流 SQL 数据库（MySQL、PostgreSQL、SQL Server、Oracle）原生支持 | |
| 物化视图支持 | ❌ MySQL 原生不支持（需模拟，如用定时任务+普通表） ✅ PostgreSQL（v9.3+）、Oracle、SQL Server（索引视图）、Snowflake、BigQuery 等支持 |
🔹适用场景对比：
✅普通视图适用场景：
• 权限控制（如只暴露部分列/行给某用户）；
• 封装复杂查询逻辑，提升 SQL 可读性与复用性；
• 需要强一致性的业务（如金融交易状态实时展示）；
• 数据量小或查询本身轻量，性能敏感度低。✅物化视图适用场景：
•报表/BI 分析：频繁查询聚合结果（如日销售额、用户地域分布），且容忍分钟/小时级延迟；
•加速慢查询：对大宽表做多维聚合、连接后结果固定，避免重复计算；
•读多写少 + 网络/计算资源受限环境（如边缘分析、数据仓库分层汇总）；
• 需要为查询创建独立索引（普通视图无法建索引，而物化视图底层是真实表，可建 B-tree、BRIN、GIN 等索引）。
💡 补充说明：
- PostgreSQL 中物化视图默认不自动刷新，需显式调用
REFRESH MATERIALIZED VIEW（支持并发刷新CONCURRENTLY）； - Oracle 的物化视图支持多种刷新模式（
FAST/COMPLETE/FORCE）及自动刷新（基于ON COMMIT或定时器）； - MySQL 用户可通过「定期
INSERT INTO ... SELECT到普通表 + 事件调度器」模拟物化视图行为。