视图是保存的SELECT语句，不存储数据、无缓存、强实时；不可更新若含JOIN、聚合、表达式或基表字段缺失NOT NULL约束；ALGORITHM和SQL SECURITY参数影响性能与安全；不可作缓存，核心价值在于逻辑解耦。
视图就是一条保存下来的 SELECT 语句
MySQL 中的视图（VIEW）不是真实表，也不存数据，它本质上是一条被命名、存储在数据库字典里的 SELECT 查询。每次你执行 SELECT * FROM my_view，MySQL 都会实时重跑那条原始查询，从基表中动态拉取最新结果。
这决定了它的核心特性：零存储开销、强实时性、但无缓存加速。它不像临时表（TEMPORARY TABLE）那样有内存/磁盘实体，也完全不同于物化视图（MySQL 原生不支持，需手动用表模拟）。
为什么不能对所有视图执行 INSERT/UPDATE/DELETE
视图是否可更新，取决于其定义是否满足 MySQL 的「可更新性规则」。违反任一条件，执行写操作就会报错 ERROR 1393 (HY000): Can not modify more than one base table through a join view 或类似提示。
- 含
JOIN多表（哪怕只是INNER JOIN）→ 默认不可更新 - 含聚合函数（
COUNT()、SUM()、GROUP BY、DISTINCT）→ 不可更新 - 字段来自表达式或常量（如
id + 1 AS new_id）→ 对应列不可更新 - 基表字段缺失
NOT NULL且无默认值 → 即使单表视图，INSERT也可能失败
创建视图时最容易忽略的两个参数
ALGORITHM 和 SQL SECURITY 虽然常被省略，但在生产环境必须心里有数：
-
ALGORITHM = MERGE（默认）：MySQL 把视图查询“合并”进外部查询一起优化，性能通常更好；但若视图含子查询或复杂逻辑，可能触发TEMPTABLE回退，导致无法使用基表索引 -
SQL SECURITY DEFINER（默认）：视图以创建者权限执行，而非调用者权限——这意味着即使普通用户没权限查基表，只要能访问该视图，就可能间接读取敏感数据，安全风险隐蔽
显式写成 CREATE ALGORITHM = MERGE SQL SECURITY INVOKER VIEW v_user_safe AS ... 才真正可控。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
别把视图当缓存用，尤其在大数据量场景
有人以为建个视图就能“固定住慢查询结果”，这是典型误解。视图不缓存、不索引、不落盘。如果底层 SELECT 涉及百万级连接或全表扫描，每次查视图都重新算一遍，响应时间波动极大。
真实可行的替代方案只有两个：
- 对高频只读结果，用普通表 + 定时任务（
REPLACE INTO summary_table SELECT ...）手动物化 - 升级到 MySQL 8.0+ 后，用
CTE（公用表表达式）配合应用层缓存，比视图更灵活
视图真正的价值，从来不在性能，而在解耦——把“怎么查”藏起来，只暴露“查什么”。一旦开始纠结它快不快，说明用错了地方。
