mysql视图select权限不自动继承底层表权限，必须显式授予视图权限；若视图设为sql security definer且定义者有表权限，则用户仅需视图权限即可查询，否则需同时拥有视图及所有依赖表的select权限。
视图 SELECT 权限本身不自动继承底层表权限
直接对视图执行 GRANT SELECT ON view_name TO 'user'@'host' 不会生效——MySQL 会拒绝查询，报错 ERROR 1142 (42000): SELECT command denied to user。这是因为 MySQL 的权限检查是「双层验证」：用户既要拥有视图本身的 SELECT 权限，也必须对视图定义中引用的所有基础表（或视图）拥有对应权限。
但注意：这个「必须拥有表权限」的规则，仅在用户以常规方式访问视图时触发；若使用 SQL SECURITY DEFINER 创建视图，则可绕过该限制。
- 默认创建视图时使用的是
SQL SECURITY DEFINER（即以定义者身份执行），只要定义者（如 root）有底层表权限，普通用户查视图就不需要自己再有表权限 - 若显式指定
SQL SECURITY INVOKER，则每次查询都校验调用者权限，此时用户必须同时拥有视图 + 所有依赖表的SELECT - 检查现有视图安全属性：查
INFORMATION_SCHEMA.VIEWS表的SECURITY_TYPE字段
用 SQL SECURITY DEFINER 实现真正的“只给视图、不给表”
这是实现敏感数据脱敏访问的核心机制。它让视图像一个「权限代理」：定义者负责兜底权限，调用者只需被授予视图权限即可安全访问脱敏结果。
创建视图时必须显式声明：
CREATE VIEW v_user_basic AS SELECT id, name, email_domain(email) AS email FROM users WITH CASCADED CHECK OPTION SQL SECURITY DEFINER;
-
SQL SECURITY DEFINER是关键，缺省值虽也是 DEFINER，但显式写出更可靠，避免因 MySQL 版本或 SQL_MODE 差异导致隐式降级 - 确保该视图由高权限账户（如
'root'@'localhost'）创建——定义者的权限会被用于执行视图查询 - 脱敏逻辑（如
email_domain()函数）必须已存在且定义者有 EXECUTE 权限 - 不要用
WITH CHECK OPTION除非你要限制 INSERT/UPDATE，它对 SELECT 无影响，但可能干扰后续 DML
授予权限时只操作视图对象，不碰原表
确认视图已用 DEFINER 创建后，授权就变得干净利落：
GRANT SELECT ON mydb.v_user_basic TO 'reporter'@'%';
- 只写视图全名
mydb.v_user_basic，不写底层表mydb.users - 无需对
users表执行任何GRANT，reporter 用户执行SELECT * FROM v_user_basic就能返回脱敏数据 - 如果误授了
SELECT ON mydb.users，脱敏就失效了——务必用SHOW GRANTS FOR 'reporter'@'%'复核，结果里不应出现任何基础表名 - 若用户需跨库访问（比如视图引用
logdb.events），定义者也必须对logdb.events有权限，否则视图本身会创建失败或查询报错
容易被忽略的三个破坏性细节
即使上述步骤全对，仍可能因以下原因导致脱敏失效或权限拒绝：
- 视图定义中用了用户自定义函数（UDF）或存储函数，但该函数的
SQL SECURITY是INVOKER——函数执行时会校验 reporter 权限，而 reporter 没有源表权限，直接报错 - 视图依赖的某个表被重命名或 DROP，但视图未重建，此时查视图会报
ERROR 1356 (HY000): View 'mydb.v_user_basic' references invalid table(s) or column(s)，且SHOW CREATE VIEW看不到错误，必须查INFORMATION_SCHEMA.VIEWS的IS_UPDATABLE字段是否为NO - MySQL 8.0+ 开启了
check_proxy_users或启用了 PAM 认证插件，某些 proxy 用户场景下DEFINER权限可能被拦截，需确认information_schema.role_edges中无意外角色继承
