MySQL 5.7中GRANT授权报错如何解决_检查是否存在对应用户账号
GRANT报错应先确认用户是否存在，因MySQL 5.7中无CREATE USER权限时GRANT ... IDENTIFIED BY会静默忽略建用户，导致mysql.user表无记录，需用SELECT User,Host FROM mysql.user精确查询。
GRANT报错前先确认用户是否存在
MySQL 5.7 中执行 GRANT 报错（如 ERROR 1141 (42000): There is no such grant defined for user 'u'@'h' on host 'h' 或直接 Access denied），第一反应不应该是改权限语句，而是查这个用户账号到底有没有被真正创建出来。
常见误区是以为 GRANT ... IDENTIFIED BY 一定能建用户——它确实能，但前提是执行者本身有 CREATE USER 权限，且没被 skip-grant-tables 或权限表损坏干扰。很多报错实际源于「用户行在 mysql.user 表里根本不存在」。
- 用
SELECT User, Host FROM mysql.user WHERE User = 'u';精确查，注意大小写和@'%'与@'localhost'是不同账号 - 如果查不到，说明
GRANT ... IDENTIFIED BY没生效，或被跳过了（比如你连的是从库、或当前用户没有Grant_priv = Y） - 不要依赖
SHOW GRANTS FOR 'u'@'%'的输出：若用户不存在，它会直接报错ERROR 1141，而不是返回空 - 检查
mysql.user表中该用户的plugin字段是否为mysql_native_password；如果是空、auth_socket或其他未加载插件（如报ERROR 1524），即使行存在也无法登录
为什么GRANT后用户仍查不到
最典型的场景是：你用普通管理员账号（比如 'admin'@'%'）执行了 GRANT SELECT ON db.* TO 'u'@'%' IDENTIFIED BY 'p';，但该 admin 账号自身没有 CREATE USER 权限，MySQL 就会静默忽略建用户动作，只尝试赋权——而因为用户不存在，赋权也失败，最终 mysql.user 表无新增，GRANT 语句却返回 Query OK（这是 5.7 的一个误导性行为）。
验证方式很简单：
- 执行完
GRANT后立刻SELECT User, Host, plugin FROM mysql.user WHERE User = 'u'; - 如果结果为空，说明建用户失败；如果存在但
plugin是''或unix_socket，说明认证方式不兼容客户端 - 此时应改用显式两步：
CREATE USER 'u'@'%' IDENTIFIED WITH mysql_native_password BY 'p';，再GRANT ... TO 'u'@'%';
FLUSH PRIVILEGES 是否必要
在 MySQL 5.7 中，只要你是通过 CREATE USER 或 GRANT 正常操作，FLUSH PRIVILEGES 完全不需要。它只对直接 UPDATE mysql.user 这类绕过权限系统的方式生效。
滥用 FLUSH PRIVILEGES 反而容易掩盖问题：
- 如果你在从库上执行它，不会同步到主库，导致权限不一致
- 如果权限表结构损坏（比如升级后未跑
mysql_upgrade），FLUSH会失败但不报错，让你误以为操作成功 - 它不能修复
plugin字段错误或密码策略拦截（如ERROR 1819）
容易被忽略的权限源头问题
即使你确认用户存在、plugin 正确、密码策略已调低，GRANT 仍失败，大概率是执行者账号本身权限不足。重点检查：
-
SELECT Grant_priv FROM mysql.user WHERE User = 'your_admin' AND Host = 'your_host';必须为Y - 如果用的是
'root'@'%'，注意它和'root'@'localhost'是两个独立账号，后者通常有完整权限，前者可能被限制 - 某些云数据库（如阿里云 RDS）默认禁用
GRANT OPTION，即使你看到ALL PRIVILEGES，实际无法转授，此时GRANT ... WITH GRANT OPTION必然失败
真正卡住的地方往往不是语法，而是「谁在执行」和「执行者自己有没有资格执行」——这两点比记住 GRANT 写法重要得多。
