SQL Server中视图真只读需显式拒绝DML权限：GRANT SELECT并DENY INSERT/UPDATE/DELETE，因仅靠WITH CHECK OPTION无法拦截INSERT且无法阻止绕过视图直改底层表。
SQL Server 中如何让视图只读（不走 WITH CHECK OPTION 的坑）
视图本身默认就是只读的——但这是假象。只要底层表允许 INSERT/UPDATE，且视图没做结构限制，用户仍可能通过 INSERT INTO view_name 或 UPDATE view_name 间接修改数据。真要锁死写入，不能只靠“看起来不能改”。
真正起效的方式是：在创建视图时显式加上 WITH CHECK OPTION，但这只约束 UPDATE/DELETE 的行可见性，对 INSERT 无强制拦截作用；更可靠的做法是配合权限控制——直接拒掉对视图的 INSERT、UPDATE、DELETE 权限。
-
GRANT SELECT ON view_name TO user_role—— 只给查，别的全不给 - 别漏掉
DENY INSERT, UPDATE, DELETE ON view_name TO user_role—— 显式拒绝比单纯不授更安全（尤其当用户有底层表权限时） - 如果用户已有底层表的写权限，
WITH CHECK OPTION无法阻止他们绕过视图直改表，所以权限隔离必须做在视图层
PostgreSQL 视图默认可写？怎么关掉
PostgreSQL 的视图默认是只读的，但一旦视图定义满足“可更新视图”条件（比如只查一张表、无聚合、无 DISTINCT、无 CTE 等），它就自动变成可写的——连 INSERT 都能成功执行，非常隐蔽。
最稳妥的关闭方式不是改视图逻辑，而是用权限+规则双保险：
- 执行
REVOKE INSERT, UPDATE, DELETE ON view_name FROM PUBLIC（或具体角色） - 再加一条
CREATE RULE "_RETURN" AS ON SELECT TO view_name DO INSTEAD SELECT * FROM underlying_table WHERE ...—— 这步不是必须，但能彻底屏蔽任何写意图（规则优先级高于权限，不过一般只用权限就够了） - 注意：PostgreSQL 12+ 支持
CREATE VIEW ... WITH (security_invoker = true)，但它影响的是执行上下文，不控制读写权限
MySQL 视图的 READ ONLY 属性怎么设才生效
MySQL 提供了 ALGORITHM = TEMPTABLE 和 SQL SECURITY DEFINER 等选项，但真正控制读写的是 READ ONLY 属性——但它只在创建时指定，后续不能 ALTER 修改。
必须一步到位：
- 建视图时明确写
CREATE ALGORITHM = MERGE DEFINER = 'user'@'%' SQL SECURITY DEFINER VIEW v_name AS SELECT ... WITH READ ONLY - 漏掉
WITH READ ONLY，哪怕你只给了SELECT权限，用户仍可能触发ERROR 1471 (HY000): The target table v_name of the INSERT is not insertable-into这类报错——这不是保护，是失败后才拦，体验差且不可控 - MySQL 8.0.19+ 支持
CREATE VIEW ... WITH CHECK OPTION，但它和 SQL Server 一样，仅校验 UPDATE/INSERT 后的数据是否还符合视图定义，不禁止操作本身
跨数据库统一处理只读视图的权限陷阱
不同数据库对“视图可写”的判定逻辑差异很大：SQL Server 看权限，PostgreSQL 看定义结构，MySQL 看是否声明 READ ONLY。想统一管控，不能依赖某一种机制。
最小化权限落地的关键动作只有两个：
- 所有环境都执行：只
GRANT SELECT，显式DENY（SQL Server）或REVOKE（PG/MySQL）其余 DML 权限 - 禁止给用户授予底层基表的任何权限——否则视图上的只读形同虚设
- 自动化部署时，检查脚本是否包含
SELECT以外的GRANT，这类语句必须被拦截或告警
权限这东西，看不见摸不着，但一松动，数据就可能从视图背后被改掉。最简单的办法，往往是最容易被跳过的那步：确认 DENY INSERT ON view_x TO role_y 真的执行成功了，而不是只写了注释。
