MySQL视图权限独立于基础表，需显式授权；默认SQL SECURITY DEFINER模式下，仅需视图权限；INVOKER模式则要求调用者同时拥有视图及底层表权限；字段级控制须通过精简视图定义或8.0+列权限实现。
视图权限和基础表权限是分开管理的
MySQL 中对 VIEW 的访问控制不继承自底层表权限。即使你给了用户对 users 表的 SELECT 权限，也不代表他能查 user_view 视图——必须显式授权。这是因为视图在执行时会以定义者（DEFINER）或调用者（INVOKER）身份校验权限，而默认是 DEFINER 模式。
常见错误现象：ERROR 1142 (42000): SELECT command denied to user 'u1'@'%' for table 'user_view'，但该用户明明能查原表。
- 创建视图时若未指定
DEFINER，MySQL 会自动设为当前用户，且该用户必须拥有底层表的对应权限 - 授权给视图必须用
GRANT SELECT ON database.view_name TO 'user'@'%'，不能写成GRANT SELECT ON database.table_name - 若视图依赖多个表，用户只需有该视图的
SELECT权限，无需知道或持有底层各表的权限（前提是视图用SQL SECURITY DEFINER）
SQL SECURITY DEFINER 和 INVOKER 决定权限检查时机
这是最容易被忽略的权限逻辑分水岭。视图（以及存储过程、函数）的 SQL SECURITY 属性决定了运行时按谁的权限检查：
-
DEFINER（默认）：以视图创建者身份检查权限，调用者只需有视图本身的权限 -
INVOKER：以调用者身份检查权限，调用者必须同时拥有视图 + 所有底层表的对应权限
查看当前视图的定义方式：
SHOW CREATE VIEW mydb.user_view;输出中会明确写出
SQL SECURITY DEFINER 或 SQL SECURITY INVOKER。
修改已有视图的 security 属性需重建：
CREATE OR REPLACE ALGORITHM=MERGE SQL SECURITY INVOKER VIEW mydb.user_view AS SELECT id, name FROM users;
GRANT 后必须 FLUSH PRIVILEGES 吗？
绝大多数情况下不需要。MySQL 5.7+ 和 8.0 中，GRANT 语句本身就会即时刷新权限缓存。只有当你直接操作 mysql 系统库表（如手动 INSERT INTO mysql.tables_priv）后才需要 FLUSH PRIVILEGES。
典型误操作：
GRANT SELECT ON mydb.user_view TO 'reporter'@'%';<br>FLUSH PRIVILEGES;这行
FLUSH PRIVILEGES 不仅多余，还可能掩盖真正问题（比如用户 host 匹配失败、大小写敏感等）。
- 确认授权是否生效，优先用
SHOW GRANTS FOR 'reporter'@'%' - 检查用户连接时实际使用的 host 是否匹配（
'reporter'@'localhost'≠'reporter'@'%'） - MySQL 8.0+ 用户名/主机名区分大小写，注意引号和拼写
视图权限无法限制字段级访问？那就别依赖视图做脱敏
视图可以隐藏列，但只要用户有视图的 SELECT 权限，就能看到视图定义里暴露的所有字段。它不是行级或列级权限控制机制。
如果你希望某用户只能查 name 和 email，但不能碰 phone 和 id_card，正确做法是：
- 建一个只包含目标字段的视图，并只对该视图授权
- 不要把敏感字段放进视图定义里——一旦放进去了，哪怕加了
WHERE 1=0，元数据仍可被SHOW COLUMNS查到 - 真正需要字段级隔离，得靠 MySQL 8.0+ 的
column-level privileges（如GRANT SELECT(id,name) ON db.t TO u），但注意这不适用于视图，只作用于基表
复杂点在于：视图字段别名、计算列、函数表达式会让权限追踪变模糊；而 INFORMATION_SCHEMA.VIEWS 对普通用户默认不可见，反而让调试更困难。
