根本原因是权限链断裂：当前用户缺SELECT权限，或视图DEFINER无基表权限，或两者兼有；需先查CURRENT_USER()和SHOW GRANTS FOR CURRENT_USER()确认真实权限，再用SHOW CREATE VIEW检查DEFINER与SQL SECURITY，并逐层验证基表、跨库及角色激活状态。
普通用户无法查询新建的SQL视图数据，**根本原因不是视图本身没建好，而是权限链断裂了——要么当前用户缺 SELECT 权限，要么视图 DEFINER 无基表权限，或两者兼有。**
查 CURRENT_USER() 和真实权限，别信 USER()
执行 SELECT USER(), CURRENT_USER(); ——前者是“你声称自己是谁”，后者才是数据库真正用来校验权限的账号。常见陷阱：CURRENT_USER() 返回 'dev'@'%'，但这个账号可能只有 USAGE（仅能登录），连 SHOW DATABASES 都被拒。立刻跟一句 SHOW GRANTS FOR CURRENT_USER();，确认是否真有 SELECT 权限；若返回空或只有 GRANT USAGE ON *.*，就说明权限为零。
SHOW CREATE VIEW 看 DEFINER 和 SQL SECURITY
运行 SHOW CREATE VIEW my_view\G，重点盯两行：
• DEFINER=`admin`@`localhost`：如果该账号已被删，查视图会报 ERROR 1449；
• SQL SECURITY DEFINER：表示以 DEFINER 身份执行，此时 MySQL 不查你（CURRENT_USER）的权限，而是查 DEFINER 对每张基表有没有 SELECT。哪怕你有 GRANT SELECT ON mydb.*，DEFINER 却没被单独授过 GRANT SELECT ON mydb.orders，照样失败。
验证 DEFINER 是否存活：SELECT User, Host FROM mysql.user WHERE User = 'admin' AND Host = 'localhost';
跨库视图和嵌套视图要额外授权
如果视图里查的是 otherdb.table_a，光给当前库授权没用：GRANT SELECT ON otherdb.table_a TO CURRENT_USER(); 必须显式加。嵌套视图（如 v2 AS SELECT * FROM v1）还要求当前用户有 SHOW VIEW 权限——否则报 ERROR 1349，且错误信息完全不提权限，只说“view has errors”。
MySQL 8.0 角色权限容易漏激活
若用角色管理权限（比如 CREATE ROLE analyst; GRANT SELECT ON sales.* TO analyst;），用户被 GRANT analyst TO 'dev'@'%'; 后，**默认不自动启用角色**。必须显式执行 SET ROLE analyst;，或确保配置了 activate_all_roles_on_login=ON。否则 SHOW GRANTS 会显示角色已赋，但实际权限不生效。
最常被忽略的一点：权限问题往往不是“全无”或“全有”，而是“差一层”——DEFINER 存在但缺某张基表权限、角色已赋但未激活、跨库访问漏授权。排查必须逐层穿透，不能只停在 CURRENT_USER() 这一层。
