WITH CHECK OPTION 仅约束通过视图执行的 INSERT/UPDATE 操作，对 SELECT 无效，不能防止敏感数据泄露；它确保写入数据符合视图 WHERE 条件，但不控制读权限，也不替代显式 GRANT 权限。
WITH CHECK OPTION 是什么，它真能防住敏感数据泄露？
不能。它只约束 INSERT 和 UPDATE 操作，对 SELECT 完全无效——也就是说，用户只要能查这个视图，就能看到所有行，无论是否满足视图定义里的 WHERE 条件。
它的实际作用是：防止用户通过视图“绕过”过滤条件写入或修改数据。比如视图只暴露 status = 'active' 的记录，加了 WITH CHECK OPTION 后，用户就不能用 UPDATE 把某条 active 记录改成 inactive，也不能 INSERT 一条 status = 'deleted' 的记录进去。
- 它不控制读权限，只控制写行为的合法性
- 它不替代
GRANT SELECT/GRANT INSERT等权限管理 - 它只在视图层生效，底层表权限仍需单独配置
怎么加 WITH CHECK OPTION 才真正起效？
必须显式声明，且注意语法位置：它得放在视图定义的末尾，紧接在 AS SELECT ... 之后，不能写在中间或漏掉 WITH CHECK OPTION 字面量。
错误写法：CREATE VIEW v_active_users AS SELECT * FROM users WHERE status = 'active' WITH CHECK OPTION;（缺关键字 WITH）
正确写法：
CREATE VIEW v_active_users AS SELECT id, name, email FROM users WHERE status = 'active' WITH CHECK OPTION;
- 如果视图嵌套（基于另一个视图创建），要加
CASCADE或LOCAL：默认是CASCADE，会逐级检查所有依赖视图的条件；LOCAL只检查当前视图的WHERE - 修改已有视图时，不能直接
ALTER VIEW ... WITH CHECK OPTION，必须先DROP再重建 -
SHOW CREATE VIEW v_active_users可确认是否已启用
为什么加了 WITH CHECK OPTION 还能 UPDATE 成功？
常见原因是：用户有对底层表的直接 UPDATE 权限。WITH CHECK OPTION 只拦截“通过视图发起”的写操作，不干涉用户绕过视图、直连 users 表执行 UPDATE。
- 检查权限：运行
SHOW GRANTS FOR 'user'@'host';，确认没有授予UPDATE ON database.users - 视图写操作失败时典型报错是：
Can not insert/update into table via view because it violates the view's WITH CHECK OPTION - 如果用户还能改数据，大概率是权限没收干净，或者用了
INSERT INTO users SELECT ... FROM v_active_users这类“借道”操作
真正控制敏感视图访问，还得靠权限组合
单靠 WITH CHECK OPTION 没法实现“按角色看不同数据”，它不是行级安全策略。要限制谁能看到哪些行，必须配合 MySQL 8.0+ 的 ROW LEVEL SECURITY（需企业版）或手动建多个视图 + 精细授权。
- 例如：给财务建
v_salary_finance（无WITH CHECK OPTION，但只授SELECT给财务账号）；给 HR 建v_salary_hr（过滤掉高管字段，再加WITH CHECK OPTION防误改） - 禁止用户创建临时表或使用子查询绕过视图：考虑关闭
CREATE TEMPORARY TABLES权限 - 视图定义里避免用用户可控变量（如
@var），否则可能被注入篡改过滤逻辑
最易忽略的一点：视图定义本身是公开元数据，任何有 SHOW VIEW 权限的人都能 SHOW CREATE VIEW 看到原始 SELECT 语句——这意味着过滤条件完全暴露，别指望靠视图“隐藏逻辑”。
