直接create view后仍可insert，因视图仅封装查询逻辑，不改变底层表权限；真正实现只读需结合结构约束（如避免聚合、join）与权限隔离（回收基表写权限、仅授予视图select权）。
为什么直接 CREATE VIEW 之后还能 INSERT？
因为 SQL 标准里，CREATE VIEW 默认不带任何访问控制——它只是封装查询逻辑，底层表权限没变。用户只要对基表有 INSERT 权限，哪怕通过视图操作，照样能写入（某些数据库如 PostgreSQL 会拒绝，但 MySQL、SQL Server 默认允许）。
真正实现“只读”，靠的不是视图定义本身，而是权限隔离 + 视图结构约束。
- 先用
CREATE VIEW定义查询，确保不包含GROUP BY、DISTINCT、聚合函数、子查询等不可更新结构（否则部分数据库会自动标记为只读） - 然后立刻回收该视图所依赖的基表对目标用户的
INSERT/UPDATE/DELETE权限 - 只授予
SELECT权限——且最好只授给视图本身，而不是基表
MySQL 中怎么让视图真正不可写？
MySQL 对视图可更新性判断较宽松，即使视图含 JOIN 或 UNION，只要满足单表映射规则，仍可能被误认为可更新。最稳妥做法是显式加 WITH CHECK OPTION 并配合权限收紧。
示例：
CREATE VIEW user_summary AS SELECT id, name, email FROM users WHERE status = 'active' WITH CHECK OPTION;
注意：WITH CHECK OPTION 不防 INSERT，只防 UPDATE/INSERT 后违反 WHERE 条件；它本质是写入时做校验，不是访问控制。
- 必须搭配
REVOKE INSERT, UPDATE, DELETE ON users FROM 'app_user'@'%' - 再执行
GRANT SELECT ON user_summary TO 'app_user'@'%' - MySQL 8.0+ 支持
CREATE ALGORITHM = TEMPTABLE VIEW，这类视图天然不可更新，但性能开销大，慎用
PostgreSQL 视图默认就只读？别信
PostgreSQL 的视图确实多数情况不可写（尤其含 JOIN、GROUP BY、窗口函数），但它提供 INSTEAD OF 触发器机制，允许你手动定义写入行为——这意味着“默认只读”只是因为没人写触发器，不是语言强制。
- 检查是否可写：运行
SELECT table_name, is_updatable FROM pg_views WHERE viewname = 'your_view'; - 若
is_updatable = 'YES'，说明它可能被意外修改，需用REVOKE显式禁用 - 更彻底的做法：用
CREATE VIEW ... AS SELECT ... WITH NO SCHEMA BINDING（仅 SQL Server 支持），PG 不支持该语法，只能靠权限和结构双重保险
SQL Server 的 SCHEMABINDING 是关键
SQL Server 下，SCHEMABINDING 不仅防止基表结构变更影响视图，还会让大多数复杂视图变成不可更新状态——这是少数几个靠语法就能强化只读语义的场景。
写法示例：
CREATE VIEW dbo.active_users WITH SCHEMABINDING AS SELECT u.id, u.name, u.email FROM dbo.users u WHERE u.status = 'active';
- 必须用两段式名称（
dbo.users），否则SCHEMABINDING创建失败 - 创建后，基表字段不能删、不能改类型，也不能删掉被引用的列
- 即使这样，仍建议额外执行
REVOKE INSERT, UPDATE, DELETE ON dbo.active_users FROM [role]，因为权限优先级高于语法限制
sys.database_permissions（SQL Server）或 information_schema.role_table_grants（PG），确认写权限真的没了。
