直接CREATE VIEW不能阻止UPDATE，因其仅保存查询定义而不控制权限；真正只读需撤销用户对基表的写权限并仅授视图SELECT权，配合角色权限审查与专用只读账号。
为什么直接 CREATE VIEW 不能阻止 UPDATE
SQL 标准中，CREATE VIEW 本身不带访问控制语义——它只是保存一个查询定义。即使视图只包含 SELECT，只要底层表可写、用户有对应权限，数据库仍可能允许通过视图执行 UPDATE、INSERT 或 DELETE（尤其当视图基于单表且不含计算列、聚合、DISTINCT 等“不可更新”特征时）。PostgreSQL 和 SQL Server 就可能让简单单表视图被意外修改。
用 WITH CHECK OPTION 实现逻辑只读（但不够）
WITH CHECK OPTION 的作用是约束「通过视图插入/更新的数据必须能被该视图查出来」，它防的是数据逻辑不一致，不是防 DML 操作本身。它不禁止 UPDATE，反而可能让更新失败（触发检查失败报错），但用户仍可发起修改请求——这不是真正意义上的只读。
- 适用场景：需要确保视图数据边界（如
WHERE status = 'active'），但不解决「禁止任何修改」需求 - 错误认知：加了
WITH CHECK OPTION就等于视图不可写 → 实际上单表视图仍可UPDATE - 示例：
CREATE VIEW active_users AS SELECT id, name FROM users WHERE status = 'active' WITH CHECK OPTION;
此时UPDATE active_users SET name='x' WHERE id=1仍会成功（只要更新后status还是'active'）
真正只读：靠权限控制 + 视图定义组合
只读视图的本质是「用户无权修改底层表」，而非视图自身有只读属性。必须切断用户对基表的 UPDATE/INSERT/DELETE 权限，并仅授予 SELECT 权限（含对该视图的 SELECT）。视图只是查询封装，权限才是开关。
- 先撤销用户对基表的写权限：
REVOKE INSERT, UPDATE, DELETE ON users FROM app_reader;
- 再显式授予视图的
SELECT权限（非必须，但更清晰）：GRANT SELECT ON active_users TO app_reader;
- 关键点：用户角色不能属于
db_owner、sysadmin等高权限组；否则权限撤销无效 - 验证是否生效：用目标用户连接后执行
UPDATE active_users SET ...，应报错类似permission denied for table users（PostgreSQL）或The user does not have permission to perform this action（SQL Server）
进阶防护：用安全策略或函数封装绕过权限漏洞
某些场景下（如共享数据库、多租户应用），仅靠 GRANT/REVOKE 不够稳健——DBA 可能误授、角色继承关系复杂、或需动态过滤。这时可叠加机制：
- SQL Server：启用
VIEW DEFINITION权限隔离 +SCHEMABINDING视图（防止基表结构变更影响视图，间接提升稳定性）：CREATE VIEW active_users WITH SCHEMABINDING AS SELECT id, name FROM dbo.users WHERE status = 'active';
- PostgreSQL：用
SECURITY DEFINER函数替代视图，函数内硬编码SELECT并设为只读执行上下文（避免调用者权限干扰） - 通用建议：在应用层连接字符串中使用专用只读账号，该账号在建库脚本中就只被赋予视图
SELECT权限，不接触任何基表
最常被忽略的是权限层级穿透——比如给用户授了 SELECT on view，却忘了他所属的角色仍有 UPDATE on table。只读视图不是魔法开关，它是权限体系里的一环，缺一不可。
