执行GRANT失败主因是当前用户缺GRANT OPTION权限，需用SHOW GRANTS验证并补全；目标库不存在、MySQL 8.0+禁用GRANT中IDENTIFIED BY、user@host不匹配或认证插件不兼容也会导致失败。
执行 GRANT 语句后提示 Access denied，不是语法写错了，而是你当前登录的用户压根没资格执行授权操作——MySQL 检查的是“你有没有 GRANT OPTION”，不是“你是不是 root”。
你的账号缺 GRANT OPTION 权限
即使你是 'root'@'localhost' 登录，SHOW GRANTS FOR CURRENT_USER(); 输出里没有 WITH GRANT OPTION，GRANT 就会失败（或静默不生效）。这不是 bug，是 MySQL 的权限隔离设计。
- 检查方式：
SHOW GRANTS FOR CURRENT_USER();，重点看最后一行是否含WITH GRANT OPTION - 补权限：运行
GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION; - 必须跟
FLUSH PRIVILEGES;（尤其在 MySQL 5.7 或低配环境里，不刷可能不生效） - 注意：MySQL 8.0+ 默认安装的
root账号往往就没有GRANT OPTION，别 assume
目标数据库根本不存在
GRANT SELECT ON mydb.* TO 'u'@'%'; 报 ERROR 1044 或 ERROR 1146？不是权限问题，是 mydb 这个库还没建。MySQL 在解析 mydb.* 时会先校验库是否存在，不存在直接拒掉，不往下走权限逻辑。
- 先确认库存在：
SHOW DATABASES LIKE 'mydb'; - 不存在就建：
CREATE DATABASE IF NOT EXISTS mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 再执行
GRANT，顺序不能颠倒 - Linux 下注意大小写敏感，
GRANT ... ON MyDB.*和CREATE DATABASE mydb是两个库
MySQL 8.0+ 用了 IDENTIFIED BY 写法
在 MySQL 8.0+ 执行 GRANT SELECT ON db.* TO 'u'@'%' IDENTIFIED BY 'pwd'; 必报 ERROR 1064 或 ERROR 1410。这个语法从 8.0 开始被彻底移除，不是拼写问题，是语言级废弃。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 必须拆成两步：
CREATE USER 'u'@'%' IDENTIFIED BY 'pwd';→GRANT SELECT ON db.* TO 'u'@'%'; - 如果用户已存在，改密码用
ALTER USER 'u'@'%' IDENTIFIED BY 'newpwd';，绝不能塞进GRANT - 已有脚本批量迁移时，grep -r "IDENTIFIED BY" . | grep GRANT 就能快速定位风险点
权限看起来给了，但新用户连不上
GRANT 成功返回 Query OK，但新用户仍报 Access denied for user 'u'@'%'，大概率是 user@host 组合不匹配，或者认证插件不兼容。
- 查真实账号：
SELECT User, Host FROM mysql.user WHERE User = 'u';，确认输出里真有'u'@'%'（注意单引号和百分号是字面值） - 检查插件：
SELECT plugin FROM mysql.user WHERE User = 'u' AND Host = '%';，如果是caching_sha2_password，老 PHP/Python 客户端常握手失败 - 临时切插件：
ALTER USER 'u'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd';+FLUSH PRIVILEGES; - 远程连接还要看
bind_address是否监听外网（ss -tlnp | grep :3306看是否含*:3306）
最易忽略的其实是 Host 字符串的**字面精确性**：MySQL 不做 DNS 解析、不自动转 IPv4/v6、不通配子网。你连的是 'u'@'192.168.1.100'，表里只有 'u'@'192.168.1.%'？不行。必须一模一样。
