WITH CHECK OPTION 是视图的约束机制，仅对通过视图执行的 INSERT/UPDATE 生效，强制修改后数据仍满足视图 WHERE 条件；它不约束 DELETE、SELECT 或直接操作基表，对多表连接、聚合等不可更新视图无效。
视图默认不支持INSERT，别误以为能写就等于能安全写
大多数数据库（PostgreSQL、SQL Server、MySQL 8.0+）的普通视图默认禁止 INSERT / UPDATE / DELETE，除非显式满足可更新条件。但一旦你加了 WITH CHECK OPTION 或用了可更新视图语法，就进入了“表面能写、实际危险”的区域——用户可能绕过 WHERE 过滤插入本不该进的数据。
WITH CHECK OPTION 是防止越权插入的核心机制
它强制所有通过视图执行的 INSERT 和 UPDATE 操作，必须满足视图定义中的 WHERE 条件。否则直接报错，不入库。
- 没加
WITH CHECK OPTION：用户执行INSERT INTO v_dept_a SELECT * FROM users WHERE dept = 'B'可能成功（如果底层表权限允许），哪怕视图只定义为WHERE dept = 'A' - 加了
WITH CHECK OPTION：同样语句会报错new row violates check option for view v_dept_a - MySQL 要求用
CASCADED（默认）或LOCAL；PostgreSQL 支持WITH CHECK OPTION和WITH LOCAL CHECK OPTION，后者只检查当前视图条件，不递归检查嵌套视图 - 注意：该选项对
UPDATE同样生效，但只校验 SET 后的行是否仍满足视图条件，不校验原始行是否属于该视图
可更新视图的底层限制必须手动满足
即使加了 WITH CHECK OPTION，视图本身也得先“够格”才能接受写操作。常见卡点：
- 视图定义不能含
DISTINCT、聚合函数（SUM、COUNT）、GROUP BY、HAVING、子查询（在 SELECT 列表中）、UNION—— 这些会让视图不可更新 - 必须只引用单个基表（多表 JOIN 视图基本不可更新，除非用
INSTEAD OF触发器） - SELECT 列必须是基表的**基础列**，不能是表达式（如
price * 1.1）或常量（如'active'） - PostgreSQL 中，若视图含
LEFT JOIN，只有“主表”侧的列才可能被更新；MySQL 完全不支持 JOIN 视图的写入
真正防越权，得靠权限 + 视图 + CHECK OPTION 三件套
单独依赖视图逻辑是脆弱的。攻击者只要拿到对基表的 INSERT 权限，就能绕过视图直接写。
- 先
REVOKE INSERT ON TABLE users FROM app_user，确保用户无法直连基表 - 再
GRANT INSERT, UPDATE ON v_dept_a TO app_user，只开放视图写权限 - 创建视图时务必带
WITH CHECK OPTION，例如：CREATE VIEW v_dept_a AS SELECT id, name, dept FROM users WHERE dept = 'A' WITH CHECK OPTION - MySQL 用户注意：视图算法要用
ALGORITHM = UNDEFINED或TEMPTABLE，MERGE算法下某些条件可能被优化掉，导致 CHECK OPTION 失效
最易被忽略的是：WITH CHECK OPTION 不会阻止用户通过其他视图或存储过程间接越权。如果业务里存在多个视图链或动态 SQL，CHECK OPTION 的保护范围仅限于当前视图层级。
