MySQL查视图报ERROR 1142并非因缺少视图SELECT权限，而是SQL SECURITY DEFINER模式下校验DEFINER账号对基表的权限：若DEFINER账号不存在、无对应基表SELECT权或角色未激活，即使当前用户已授视图权限仍会失败。
不是权限没给，而是权限校验路径被绕过去了——MySQL查视图时根本不会只看你有没有 SELECT ON view_name 这一条权限。
为什么 SHOW GRANTS 显示有权限，但 SELECT * FROM view_name 仍报 ERROR 1142？
因为 MySQL 在执行视图查询时，会根据视图的 SQL SECURITY 属性决定用谁的身份去检查基表权限：
- 如果视图是
SQL SECURITY DEFINER（默认），MySQL 会去验证DEFINER账号对所有底层表是否有SELECT权限，而不是当前用户 - 如果
DEFINER账号已删除、密码过期、或只被授予了库级权限（如GRANT SELECT ON mydb.*），但没单独授每张基表（如GRANT SELECT ON mydb.users），就会在运行时报ERROR 1449或ERROR 1142 - 即使你显式给了当前用户
SELECT ON view_name，只要DEFINER权限链断了，查询照样失败
如何快速定位是 DEFINER 问题还是当前用户权限问题？
分两步查，顺序不能错：
- 先确认当前连接身份：
SELECT USER(), CURRENT_USER();—— 如果两者 host 不一致（比如'app'@'10.0.1.%'vs'app'@'%'），CURRENT_USER()才是真正参与权限校验的账号 - 再查真实生效权限：
SHOW GRANTS FOR CURRENT_USER();—— 注意不是FOR 'app'@'10.0.1.%'，后者可能根本没权限执行 - 最后看视图定义：
SHOW CREATE VIEW your_view\G，重点抓DEFINER=`xxx`@`yyy`和SQL SECURITY行 - 用
SELECT User, Host FROM mysql.user WHERE User = 'xxx' AND Host = 'yyy';确认 DEFINER 账号是否还存在
GRANT SELECT ON view_name 为什么经常不够用？
它只是开了“门”，但门后每一道锁（基表）都得单独配钥匙：
- 视图引用了
orders、customers、products三张表？那你得分别执行：GRANT SELECT ON sales.orders TO 'user'@'%';、GRANT SELECT ON sales.customers TO 'user'@'%';、GRANT SELECT ON sales.products TO 'user'@'%'; - 跨库更危险：视图里写了
SELECT * FROM billing.invoices，就必须单独给billing.invoices授权，GRANT SELECT ON sales.*完全无效 - 嵌套视图还要额外加
SHOW VIEW权限，否则连SHOW CREATE VIEW都执行不了，直接卡在元数据读取阶段
最容易被忽略的是：MySQL 8.0 启用角色后，CURRENT_USER() 可能绑着一个角色，但该角色没被激活（SET ROLE role_name; 没执行，且 activate_all_roles_on_login 关闭），这时 SHOW GRANTS FOR CURRENT_USER() 显示的仍是空权限集。
