MySQL视图权限独立于基础表，需显式授权；SQL SECURITY INVOKER更安全；CHECK OPTION防止越界DML；权限变更即时生效但依赖连接状态。
视图权限和基础表权限是分开控制的
MySQL 不会自动继承底层表的权限给视图。即使你对 orders 表有 SELECT 权限，也不代表你能查基于它的视图 v_active_orders——必须显式授予视图本身的权限。
常见错误现象：ERROR 1142 (42000): SELECT command denied to user 'u_app'@'%' for table 'v_active_orders'，但查原表却正常。
- 授予权限时目标对象写的是视图名，不是原表名：
GRANT SELECT ON mydb.v_active_orders TO 'u_app'@'%'; - 视图定义中若引用了多个表，用户需对每个源表都有对应操作权限（如视图含
JOIN），否则创建或查询时可能报错ERROR 1356 - 用
DEFINER创建视图可绕过部分权限检查，但有安全风险：一旦 definer 账号被提权，视图就成后门入口
用 SQL SECURITY DEFINER / INVOKER 控制执行上下文
这是最容易被忽略的权限“开关”。视图默认是 SQL SECURITY DEFINER，即以创建者身份执行；设为 INVOKER 则按调用者权限检查。
使用场景：多租户系统中，不同用户只能看到自己数据，但不想为每人建视图。
- 设为
INVOKER后，即使视图查的是全局表，也会校验调用者是否有该表权限 —— 更安全，也更符合最小权限原则 - 创建时指定：
CREATE ALGORITHM=MERGE SQL SECURITY INVOKER VIEW v_my_orders AS SELECT * FROM orders WHERE uid = USER(); -
DEFINER模式下，如果 definer 是root@localhost，普通用户就能间接读取 root 有权访问的所有数据，务必谨慎
视图不能直接限制 DML 操作，但能通过 CHECK OPTION 防越界修改
视图本身不阻止 INSERT/UPDATE，但加上 CHECK OPTION 可防止插入/更新后数据“消失”在视图结果之外。
典型问题：用户往视图插了一条 status='archived' 的记录，但视图只显示 status='active'，导致数据不可见、业务逻辑断裂。
- 加约束：
CREATE VIEW v_active_orders AS SELECT * FROM orders WHERE status='active' WITH CHECK OPTION; - 此时
INSERT INTO v_active_orders (status, ...) VALUES ('archived', ...);会直接报错ERROR 1369 (HY000): CHECK OPTION failed -
LOCAL和CASCADED的区别在于嵌套视图场景，一般用默认的CASCADED即可
权限变更后需要 FLUSH PRIVILEGES 吗？
不需要。对视图执行 GRANT 或 REVOKE 后，权限立即生效，不依赖 FLUSH PRIVILEGES。
但注意两个边界情况：
- 如果用户当前已有活跃连接，旧连接不会自动刷新权限，需重连或等连接超时断开
- 视图依赖的底层表权限被撤回后，视图查询会立刻失败，哪怕之前已授过视图权限 —— 因为 MySQL 在运行时仍要校验基表可访问性
- 用
SHOW GRANTS FOR 'u_app'@'%';查看实际生效权限，比翻文档更可靠
权限控制的关键不在“能不能建视图”，而在“谁查、查什么、怎么查”。SQL SECURITY 模式、CHECK OPTION、显式授权这三点漏掉任意一个，都可能让视图变成数据泄露通道。
