MySQL 8.0+禁止GRANT隐式创建用户，必须先CREATE USER再GRANT授权；ERROR 1410表明语法被硬性拒绝，非权限或密码问题，且不兼容旧版IDENTIFIED BY写法。
MySQL 8.0 及以上版本中，GRANT 语句不能再自动创建用户 —— 出现 ERROR 1410 (42000): You are not allowed to create a user with GRANT 就说明你正试图用老写法一步到位建用户+授权，这在 8.0+ 已被禁用。
为什么 GRANT ... IDENTIFIED BY 在 MySQL 8.0 会报 ERROR 1410
MySQL 8.0 彻底拆分了「用户生命周期管理」和「权限分配」两个动作。旧语法如 GRANT ALL ON *.* TO 'u'@'%' IDENTIFIED BY 'p' 本质是隐式调用了 CREATE USER，而新版本要求显式、分步执行，避免权限误授或插件配置遗漏。
- 错误不是密码不对，也不是用户已存在，而是语法不被接受
- 即使你是
root，该语法也直接拒绝，不会降级兼容 - 该限制与认证插件强相关：8.0 默认用
caching_sha2_password，IDENTIFIED BY在GRANT中无法指定插件，易导致客户端连接失败
正确操作：必须先 CREATE USER，再 GRANT
两步缺一不可，且顺序不能颠倒。推荐写法（含安全细节）：
CREATE USER 'app_user'@'10.0.2.%' IDENTIFIED WITH caching_sha2_password BY 'StrongPass!2024'; GRANT SELECT, INSERT, UPDATE ON app_db.* TO 'app_user'@'10.0.2.%'; FLUSH PRIVILEGES;
-
IDENTIFIED WITH ... BY显式声明插件，避免客户端（尤其是旧版 PHP/Python 驱动）握手失败 - Host 写具体网段（如
10.0.2.%）比%更安全，也规避 DNS 解析问题 -
FLUSH PRIVILEGES虽在多数 GRANT 后自动触发，但显式执行更可控，尤其在脚本化部署中
常见踩坑点：Host 匹配失败 & 权限不生效
即使语法正确，仍可能报 ERROR 1045 或查询被拒，核心原因常是 Host 不匹配：
- 应用连的是
127.0.0.1（TCP），但只授权了'user'@'localhost'（Unix socket），这两者在权限系统里完全独立 -
SHOW GRANTS FOR 'app_user'@'10.0.2.%'必须输出你刚授的权限；如果显示USAGE，说明GRANT没执行成功，或 Host 字符串有空格/大小写差异 - Linux 下数据库名、用户名、Host 均区分大小写；Windows 下 Host 不敏感，但建议统一小写避免混淆
如何快速验证是否修复成功
别依赖“没报错就等于成功”。真实验证要走完整链路：
- 用目标用户从授权 IP 连接：
mysql -h 172.16.3.52 -u app_user -p - 登录后立即执行：
SELECT DATABASE();和USE app_db;，确认能进库 - 查一张表：
SELECT COUNT(*) FROM app_db.users;，验证SELECT权限真正生效 - 若仍失败，立刻运行：
SELECT USER(), CURRENT_USER();—— 如果两者不同，说明 MySQL 认证时匹配到了另一个app_user记录（比如@'%'），权限更小，这才是真因
最易被忽略的是：MySQL 的权限判定发生在连接建立瞬间，它查的是 mysql.user 表中「第一个完全匹配 User + Host 的记录」，而不是你印象中“最新创建的那个”。所以删旧用户、清理重复 Host、严格控制通配符范围，比反复 GRANT 更有效。
