MySQL 8.0 移除 GRANT 中 IDENTIFIED BY 语法，必须用 CREATE USER + GRANT 两步实现用户创建与授权，且需注意认证插件兼容性及权限最小化原则。
MySQL 8.0 中直接在 GRANT 语句里写 IDENTIFIED BY 会报错，这不是你写错了，是语法被彻底移除了——必须拆成 CREATE USER + GRANT 两步，且顺序不能反。
为什么 GRANT ALL ON *.* TO 'u'@'%' IDENTIFIED BY 'pwd' 会报 ERROR 1064
MySQL 8.0 彻底剥离了用户创建与权限授予的耦合逻辑。旧版允许一步建用户+赋权+设密码，新版把这三件事拆成独立操作：CREATE USER 负责身份（含密码），GRANT 只管权限，ALTER USER 才负责改密。一旦在 GRANT 后面跟 IDENTIFIED BY，解析器直接拒掉，错误位置通常卡在 IDENTIFIED 关键字附近。
正确创建并授权用户的三步实操（缺一不可）
以给远程应用账号 app_user 授予 myapp 库全部权限为例：
- 先创建用户并设密码：
CREATE USER 'app_user'@'%' IDENTIFIED BY 's3cureP@ss2026'; - 再授予权限（不带密码）：
GRANT SELECT, INSERT, UPDATE, DELETE ON myapp.* TO 'app_user'@'%'; - 最后刷新权限缓存：
FLUSH PRIVILEGES;（虽多数场景自动生效，但加这句能避免权限延迟）
注意：CREATE USER 若重复执行会报 ERROR 1396 (HY000)；此时应改用 ALTER USER 'app_user'@'%' IDENTIFIED BY 'newpass'; 更新密码，而不是重跑 CREATE USER。
连得上但认证失败？大概率是 caching_sha2_password 插件不兼容
即使语法全对、FLUSH PRIVILEGES 也执行了，客户端仍提示 “Access denied” 或卡在连接后断开，很可能是新用户默认用了 caching_sha2_password 认证插件，而你的 JDBC 驱动、旧版 MySQL Workbench 或 PHP mysqli 不支持它。
- 创建时强制指定兼容插件：
CREATE USER 'app_user'@'%' IDENTIFIED WITH mysql_native_password BY 's3cureP@ss2026'; - 或全局降级（需重启服务）：在
/etc/my.cnf的[mysqld]段加default_authentication_plugin=mysql_native_password
这个点不会报语法错误，也不会阻断 SQL 执行，但会让应用死在连接握手阶段——排查时容易漏掉，建议从第一个用户创建起就明确插件策略。
权限范围与安全边界别踩坑
GRANT ALL PRIVILEGES ON *.* 是高危操作，生产环境应严格限制：
- 避免全局授权，优先按库限定：
GRANT SELECT, INSERT ON billing_db.* TO 'app_user'@'%'; - 来源 IP 尽量不用
%，改用具体段如'10.10.20.%'或容器固定网段 -
WITH GRANT OPTION慎加，它允许该用户再给别人授权，极易失控 - 若只需读写某几张表，授权粒度可细化到
ON billing_db.invoice_log
真正麻烦的不是语法写不对，而是权限开太大又没监控——等某天发现数据被误删或导出，回溯时才发现那个 @'%' 用户早该锁源 IP 或砍掉 DROP 权限。
