视图就是一条保存下来的 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 ...才真正可控。
别把视图当缓存用，尤其在大数据量场景
有人以为建个视图就能“固定住慢查询结果”，这是典型误解。视图不缓存、不索引、不落盘。如果底层
SELECT涉及百万级连接或全表扫描，每次查视图都重新算一遍，响应时间波动极大。
真实可行的替代方案只有两个：
对高频只读结果，用普通表 + 定时任务（REPLACE INTO summary_table SELECT ...）手动物化 升级到 MySQL 8.0+ 后，用
CTE（公用表表达式）配合应用层缓存，比视图更灵活
视图真正的价值，从来不在性能，而在解耦——把“怎么查”藏起来，只暴露“查什么”。一旦开始纠结它快不快，说明用错了地方。
