WITH CHECK OPTION仅约束通过视图执行的INSERT/UPDATE操作，要求修改后数据仍满足视图WHERE条件；DELETE不受影响，不可更新视图中该选项无效，且不控制权限或直接基表操作。
WITH CHECK OPTION 只拦 INSERT/UPDATE，不拦 DELETE
它不是全局数据守门员，只在通过视图执行 INSERT 或 UPDATE 时触发校验。只要修改后该行不再满足视图的 WHERE 条件，操作就会失败；DELETE 不受任何影响，哪怕删的是“本不该存在”的行——因为删除本身不改变行内容，只移除可见性。
常见错误现象：INSERT INTO active_users (id, name, email, status) VALUES (103, 'Bob', 'b@example.com', 'pending') 报错 VIEW or function 'active_users' is not updatable because ... violates a CHECK OPTION constraint，即使 status 列没出现在视图定义中，只要插入后整行查不到，就被拒绝。
- 视图定义含
WHERE status = 'active'→ 插入status = 'inactive'必失败 -
UPDATE active_users SET status = 'archived'同样失败，哪怕只改一列 -
DELETE FROM active_users WHERE id = 101总是成功，不管有没有WITH CHECK OPTION
CASCADED 是默认行为，LOCAL 容易漏掉底层约束
当视图嵌套（比如 v3 基于 v2，v2 基于 v1），WITH CHECK OPTION 的检查范围取决于关键字。没写明时，默认是 CASCADED，即逐层向上检查所有依赖视图的 WHERE 条件；LOCAL 只验当前视图一层，可能绕过上游限制。
例如：CREATE VIEW v1 AS SELECT * FROM t1 WHERE a ，再建 <code>CREATE VIEW v2 AS SELECT * FROM v1 WHERE a > 0 WITH LOCAL CHECK OPTION。此时 INSERT INTO v2 VALUES (2) 看似只违反 v1 条件，但因 v2 用的是 LOCAL，系统不会自动去查 v1 的约束——实际执行仍会失败（MySQL 实现中仍递归检查），但语义上已弱化保护力度。
- 生产环境建议显式写
WITH CASCADED CHECK OPTION，避免依赖隐式行为 -
LOCAL适合调试或临时隔离某层逻辑，但不能替代完整校验 - 跨数据库注意：SQL Server 不支持
LOCAL/CASCADED关键字，只认WITH CHECK OPTION
不可更新视图加 WITH CHECK OPTION 没意义
如果视图本身就不支持修改（比如含 JOIN、GROUP BY、DISTINCT、聚合函数或计算列），加 WITH CHECK OPTION 不会产生任何约束效果——SQL Server 和 MySQL 都会在执行 INSERT/UPDATE 时报“视图不可更新”，根本走不到校验逻辑。
典型无效场景：CREATE VIEW user_order_summary AS SELECT u.name, COUNT(o.id) cnt FROM users u JOIN orders o ON u.id = o.user_id GROUP BY u.name WITH CHECK OPTION。这个视图连 UPDATE 都不允许，WITH CHECK OPTION 就像给锁头装个装饰性挂锁。
- 先确认视图是否可更新：单表 + 无聚合 + 主键列完整暴露 + 无计算列
- 多表
JOIN视图中，UPDATE最多只能改一张表的列，且必须明确指定目标表别名 - 含
ROW_NUMBER()或CONCAT()的列，会导致整行不可逆映射，视图直接不可更新
WITH CHECK OPTION 不解决权限问题，只管数据逻辑
它不控制谁能读、谁能写，只确保写入的数据符合视图定义的业务规则。用户仍需被授予对基表或视图的 INSERT/UPDATE 权限；若仅给视图 SELECT 权限，加了 WITH CHECK OPTION 也挡不住越权写入——因为压根没授权。
真正起作用的组合是：WITH CHECK OPTION + 视图级权限分配 + 基表权限回收。比如只给业务账号 SELECT 和 INSERT on active_users，但收回其对 users 表的直接 INSERT 权限。
- 单独加
WITH CHECK OPTION无法防止有基表权限的用户绕过视图直写 - 配合
SQL SECURITY DEFINER（MySQL）或EXECUTE AS（SQL Server）才能让视图代理权限 - 加密视图定义（
WITH ENCRYPTION）和WITH CHECK OPTION是两件事：前者防看，后者防错
容易被忽略的是：它只在 DML 经由视图路径时生效。任何直接操作基表、存储过程内硬编码 SQL、或通过其他视图间接写入的行为，都不受其约束。数据安全靠的是“路径控制+逻辑校验+权限隔离”三层叠加，而不是一个开关。
