CREATE VIEW 本身不提供只读保护，视图可更新性取决于底层表权限及数据库实现差异；“只读”需靠显式授权控制，且视图不存储数据、无快照能力，不能替代备份。
用 CREATE VIEW 定义只读视图，本质不阻止写操作
视图本身不是权限控制机制，CREATE VIEW 生成的视图默认可被 UPDATE/DELETE 作用——只要底层表允许且用户有对应权限。所谓“只读视图”，其实是靠数据库权限体系（如 GRANT SELECT ON view_name）配合实现的，不是视图定义决定的。
实操建议：
- 定义视图时避免包含
GROUP BY、聚合函数、DISTINCT、子查询等不可更新结构，否则 PostgreSQL/MySQL 会直接拒绝通过该视图修改数据（但不是“只读保护”，而是报错cannot update a view） - 在 MySQL 中，加
WITH CHECK OPTION只约束 INSERT/UPDATE 的行是否满足视图 WHERE 条件，不提供只读能力 - 真正想限制写入，必须收回用户对基表的
INSERT/UPDATE/DELETE权限，只留SELECT给视图
备份场景下，视图不能替代物理备份或逻辑导出
视图只是查询语句的封装，不存储数据，也不记录快照时间点。有人误以为“建个视图就能随时回查旧数据”，这是典型误解。
常见错误现象：
- 今天查
SELECT * FROM sales_view得到 100 行，明天基表被删了 20 行，视图立刻只剩 80 行——它从不缓存历史 - 用视图做“快速备份”，结果上线后发现恢复不了任何东西，因为没保存 DDL + 数据
正确做法：
- 需要历史数据快照？用
pg_dump --snapshot（PostgreSQL）或mysqldump --single-transaction（MySQL）生成一致性逻辑备份 - 若真要基于视图简化备份流程，可把它嵌入备份脚本中：比如用
mysqldump -u user db_name view_name > backup_view.sql，但这导出的是视图定义，不是数据
MySQL 和 PostgreSQL 对视图可更新性的处理差异明显
同样是 CREATE VIEW v AS SELECT id, name FROM users WHERE status = 'active'，两边行为可能完全不同。
关键区别：
- MySQL 默认允许通过该视图
UPDATE或DELETE行——只要WHERE条件仍匹配，哪怕你把status改成'inactive'，它也会成功执行并让该行从此不在视图里出现 - PostgreSQL 更严格：只要视图定义含
WHERE，默认就不可更新；想强行支持，得用规则（CREATE RULE）或 instead-of 触发器，复杂度陡增 - SQL Server 则要求视图必须是“简单可更新”的（单表、无聚合、无重复列名等），否则直接报错
View or function 'xxx' is not updatable
权限粒度不够细时，视图反而暴露不该看的数据
以为“只给视图权限就安全了”，但忘了视图字段可能泄露敏感信息。比如定义 CREATE VIEW user_safe AS SELECT id, email, created_at FROM users，却没意识到 email 本身已是 PII（个人身份信息）。
容易踩的坑：
- 视图里漏掉脱敏逻辑，比如没用
LEFT(email, 3) || '***@' || SPLIT_PART(email, '@', 2)类似处理 - 用户有
SELECT权限后，还能用EXPLAIN或慢查询日志反推基表结构，甚至结合错误信息（如column "password_hash" does not exist）确认字段名 - 某些数据库（如旧版 MySQL）不校验视图内引用的列权限，导致用户可通过视图间接访问自己本无权查的字段
真正可控的做法，是把视图和行级安全（RLS）、动态脱敏（如 PostgreSQL 的 SECURITY DEFINER 函数封装）一起用，而不是单独依赖视图定义。
视图不是开关，是透镜——它不改变权限，也不冻结数据，只改变你看的方式。用错地方，反而让边界更模糊。
