必须显式授予视图select权限，执行grant select on myapp.v_active_users to 'reporter'@'localhost'并flush privileges；嵌套视图需逐层检查依赖对象权限与定义有效性，仅授予权限不足以保证执行成功。
视图权限不会继承基表权限，必须显式授予
即使你对 myapp.users 表有 SELECT 权限，执行 SELECT * FROM v_active_users; 仍可能报 ERROR 1142 (42000): SELECT command denied to user 'reporter'@'localhost' for table 'v_active_users'。这是因为 MySQL 将视图视为独立对象，其权限记录在 mysql.tables_priv 中，与基表完全分离。恢复数据时若只还原了业务库而跳过了 mysql 系统库，视图权限就彻底丢失了。
如何精准补回视图的 SELECT 权限
不能靠“顺手给全库权限”蒙混过关——GRANT SELECT ON myapp.* 只覆盖表，不覆盖视图。必须明确指定视图全名：
- 先确认视图归属：执行
SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.VIEWS WHERE TABLE_NAME = 'v_active_users'; - 授予权限（注意反引号和 host 精确匹配）：
GRANT SELECT ON `myapp`.`v_active_users` TO 'reporter'@'localhost'; - 立即生效（MySQL 5.7 及更早版本必须）：
FLUSH PRIVILEGES; - 验证：
SELECT * FROM myapp.v_active_users LIMIT 1;，而非仅查基表
嵌套视图要逐层检查依赖权限
如果 v_active_users 是基于另一个视图 v_users_raw 定义的，那么只给外层授权远远不够。执行时可能不报权限错误，而是触发 ERROR 1356 (HY000): View reference invalid table or column——这是底层视图失效的表现。
排查步骤：
- 查定义：
SELECT VIEW_DEFINITION FROM INFORMATION_SCHEMA.VIEWS WHERE TABLE_SCHEMA = 'myapp' AND TABLE_NAME = 'v_active_users'; - 手动提取其中所有引用对象（包括其他视图、表、函数），逐个运行
SHOW GRANTS FOR 'reporter'@'localhost';检查是否都已授权 - 若发现某个嵌套视图本身已损坏（如
SHOW CREATE VIEW v_users_raw报错），优先修复或重建该视图，再补权限
真正容易被忽略的是：权限补全后，视图底层若存
权限只是第一道门槛。恢复后的视图可能语法合法、权限完整，但执行时报错——比如依赖的表已被删、字段名变更、或字符集不兼容导致隐式转换失败。这类问题不会出现在 SHOW GRANTS 或 FLUSH PRIVILEGES 的流程里，必须实际执行一次 SELECT 才暴露。尤其当视图定义中含子查询、UNION 或跨库引用时，底层对象状态比权限更难自动校验。
