<p>GRANT报错“Access denied”即使root登录，首要检查是否拥有GRANT OPTION权限；若无，需执行GRANT ALL ON . TO 'root'@'localhost' WITH GRANT OPTION;并FLUSH PRIVILEGES;。</p>
GRANT命令报错“Access denied”但你是root用户？先查GRANT OPTION
MySQL里执行GRANT失败，即使你用的是root账号登录，也不代表你真有授予权限的能力。关键看这个用户是否拥有GRANT OPTION——它不是默认附带的“最高权限”，而是独立开关。
常见现象是：GRANT SELECT ON db1.* TO 'u1'@'%'; 执行成功（返回Query OK），但新用户连不上、查不了表；或者直接报ERROR 1045 (28000): Access denied，哪怕密码和主机名都对。
- 检查当前用户是否具备该权限：
SHOW GRANTS FOR CURRENT_USER();或具体指定：SHOW GRANTS FOR 'root'@'localhost'; - 如果输出里没有
WITH GRANT OPTION，说明你不能给别人授权，哪怕你是root - 补上它：
GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION; - 别忘了刷新：
FLUSH PRIVILEGES;（虽然多数情况自动生效，但加了更稳）
MySQL 8.0+下GRANT报ERROR 1064或1410？确认是否混用了IDENTIFIED BY
如果你的SELECT VERSION();返回的是8.0.x或更高（比如8.3.0），那所有带IDENTIFIED BY的GRANT语句都会被拒绝——这不是拼写错误，是语法被彻底移除。
典型错误写法：
GRANT SELECT ON mydb.* TO 'u1'@'%' IDENTIFIED BY 'pwd';
这种在5.7能跑，在8.0+直接触发ERROR 1064（语法错）或ERROR 1410（不允许用GRANT建用户）。
- 必须拆成两步：
CREATE USER+GRANT，顺序不能反 CREATE USER 'u1'@'%' IDENTIFIED BY 'pwd';-
GRANT SELECT ON mydb.* TO 'u1'@'%';（注意：这里绝不能出现IDENTIFIED BY） - 若用户已存在，改用：
ALTER USER 'u1'@'%' IDENTIFIED BY 'newpwd';
权限“看起来给了”，但实际不生效？别只查mysql.user表
执行完GRANT后，用SELECT * FROM mysql.user WHERE User='u1'\G看到Select_priv: N，不代表权限没给——因为从MySQL 5.7开始，细粒度权限（库级、表级、列级）不再全存mysql.user，而是分散在mysql.db、mysql.tables_priv等系统表里。
真正反映权限状态的方式只有一种：
- 用
SHOW GRANTS FOR 'u1'@'%';——它读取的是权限系统的最终计算结果，可信 - 如果输出里有
GRANT SELECT ON `mydb`.* TO 'u1'@'%'，说明权限已落库 - 但还要注意：权限生效依赖连接时匹配的
Host字段，'u1'@'localhost'和'u1'@'127.0.0.1'是两个不同用户
创建用户后连不上？认证插件可能卡住你
MySQL 8.0默认用caching_sha2_password插件，而很多老客户端（如旧版PHP mysqli、JDBC 5.x、某些Python驱动）不支持它——表现就是“能连上服务器，但认证失败”，报错像Access denied for user或静默断开。
这不是权限问题，是握手协议不兼容。
- 建用户时强制指定老插件：
CREATE USER 'u1'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd'; - 或全局降级（需重启）：
default_authentication_plugin=mysql_native_password写进my.cnf - 验证插件：
SELECT Host,User,plugin FROM mysql.user WHERE User='u1';
这个点常被跳过，直到应用连不上才回头翻日志。其实只要你的客户端环境明确不支持新插件，第一步就该锁定mysql_native_password。
