SELECT USER()和CURRENT_USER()不一致说明实际登录账号与预期不同，MySQL按'user'@'host'精确匹配权限，localhost与127.0.0.1视为两个独立账号，授权需严格对应连接方式。
SELECT USER() 和 CURRENT_USER() 返回不一致就别往下看了
执行 SELECT USER(), CURRENT_USER();，如果两个值不同，比如返回 'app'@'127.0.0.1' 和 'app'@'localhost'，那说明你连的压根不是你认为的那个账号。MySQL 按 user@host 组合匹配权限，而 localhost 和 127.0.0.1 在 MySQL 里是两个完全不同的 host——前者走 Unix socket，后者走 TCP/IP。你给 'app'@'localhost' 授了权，但从命令行用 mysql -u app -h 127.0.0.1 连，就会命中权限更小甚至没授权的 'app'@'127.0.0.1'。这种情况下，SHOW GRANTS FOR 'app'@'localhost' 看起来一切正常，但实际生效的是另一个账号的权限。
GRANT 后没刷缓存，或者根本没生效
虽然 MySQL 5.7+ 大多数 GRANT 操作会自动触发权限重载，但在以下场景仍需手动执行 FLUSH PRIVILEGES;：
- 你用脚本批量修改了
mysql.user或mysql.db表（比如 INSERT/UPDATE） - 在旧版本（如 5.6）或某些容器化 MySQL 实例中，自动刷新被禁用
- 你用的是 MySQL 8.0+，但授的是视图、函数或存储过程权限——这些对象权限不会随表级
GRANT自动加载
更关键的是：别只信建库脚本里写了 GRANT SELECT ON db1.* TO ...，一定要用 SHOW GRANTS FOR CURRENT_USER(); 验证当前会话真实拿到的权限。注意，USAGE 权限只代表能登录，不等于能查任何东西。
视图、函数、存储过程必须单独授权
对基表有 SELECT 权限，不代表能查基于它的视图。MySQL 不透传权限，v_active_users 是独立对象，必须显式执行：
GRANT SELECT ON `myapp`.`v_active_users` TO 'reporter'@'localhost';
同理，调用自定义函数或存储过程也需要 EXECUTE 权限，且必须针对具体对象名（如 myapp.calc_score），不能靠库级授权覆盖。如果视图定义里还嵌套了另一个视图，那每一层都得单独检查并授权——否则报错可能是 ERROR 1356（依赖失效），而不是 ERROR 1142（权限不足），容易误判。
权限层级和 DENY 规则会覆盖你的 GRANT
MySQL 的权限是分层合并的：全局 > 数据库 > 表 > 列。但有一个反直觉点：从 MySQL 8.0.16 开始，DENY 权限（通过 CREATE ROLE + DENY SELECT ON ... 设置）会直接压制更高层的 GRANT。比如你在角色上 DENY SELECT ON mysql.*，再给用户 GRANT SELECT ON *.*，查系统表依然被拒。另外，GRANT SELECT ON db1.* 不包含视图，也不包含 db1 下的函数或事件——它们各自有独立权限字段，必须单独处理。
真正容易被忽略的是：当你确认所有 GRANT 语句都写对了、FLUSH PRIVILEGES 也执行了、CURRENT_USER() 也匹配了，问题可能出在连接复用或客户端缓存上——换一个新终端重新登录，比反复查权限更有效。
