MySQL 8.0+中GRANT报错1410的直接原因是该版本彻底移除GRANT隐式建户能力，必须先CREATE USER（推荐指定mysql_native_password插件）再GRANT授权，且两者必须分步执行、顺序不可颠倒。
MySQL 8.0 不是“不能直接使用 GRANT 授权”，而是 GRANT 语句彻底失去了创建用户的能力——只要目标用户（比如 'u'@'%'）在 mysql.user 表里不存在，GRANT 就会拒绝执行，报 ERROR 1410 或 ERROR 1064。这不是权限不足、配置没开，是语法层硬拦截。
GRANT 报 ERROR 1410 的真实含义
ERROR 1410 (42000): You are not allowed to create a user with GRANT 这句话不是警告，是明确拒绝：MySQL 8.0 已移除所有隐式建户逻辑。哪怕你是 root，哪怕 host 完全匹配，只要用户记录不存在，GRANT 就不会帮你补上那一行。
- 它不关心你有没有
CREATE USER权限——这个错误发生在语义检查阶段，根本没走到权限验证 - 它和密码强度、插件类型、host 白名单都无关，只认一个事实：
'u'@'%'是否已存在于系统表中 - 如果你看到这个错，第一反应不该是改密码或换 host，而是立刻查
SELECT User, Host FROM mysql.user WHERE User = 'u';
为什么 IDENTIFIED BY 在 GRANT 里直接报 ERROR 1064
ERROR 1064 (42000) 指向的是语法解析失败。MySQL 8.0 的 parser 已完全删除对 IDENTIFIED BY 出现在 GRANT 后的识别路径。你写的这句：
GRANT SELECT ON app.* TO 'api_user'@'%' IDENTIFIED BY 'p';
在 5.7 是合法的，在 8.0 会被解析器当场截断，错误位置精准落在 IDENTIFIED BY 上。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
GRANT只保留权限分配语义，不再承载任何身份信息（密码、插件、过期策略） - 想设密码？必须用
CREATE USER或ALTER USER，且要带IDENTIFIED WITH ... BY - 漏掉
WITH或只写IDENTIFIED BY而不指定插件，CREATE USER也会报错（如ERROR 1819）
CREATE USER 必须显式声明认证插件才能连上
即使你老老实实拆成两步：CREATE USER 'u'@'%' IDENTIFIED BY 'p'; + GRANT ...，仍可能连不上——因为 MySQL 8.0 默认用 caching_sha2_password 插件，而很多客户端（PyMySQL
- 正确写法必须带插件声明：
CREATE USER 'u'@'%' IDENTIFIED WITH mysql_native_password BY 'p'; -
ALTER USER 'u'@'%' IDENTIFIED BY 'new'会悄悄把插件重置为caching_sha2_password，导致原连接突然失效 - 安全起见，不要改全局
default_authentication_plugin，只为具体用户指定插件 -
'u'@'localhost'和'u'@'%'是两个独立账户，本地连接走前者，常被忽略
脚本迁移最容易翻车的三个细节
跨版本部署时，光改语法不够，这些点不处理，照样卡住：
- 用户已存在时，
CREATE USER会报ERROR 1396；此时该用ALTER USER 'u'@'%' IDENTIFIED WITH mysql_native_password BY 'p';，而不是重试CREATE USER - 授予角色后，用户登录不会自动获得权限——必须显式执行
SET DEFAULT ROLE 'role_name'@'%'，否则SHOW GRANTS看得到绑定，实际查询仍Access denied -
FLUSH PRIVILEGES多数情况非必需（8.0 权限动态加载），但若你手动改过mysql.user表（不推荐），这句就是必须的
最常被跳过的其实是认证插件与 host 的双重匹配问题：你用 mysql_native_password 创建了 'u'@'10.0.2.%'，但应用连的是 127.0.0.1，而你没授权 'u'@'127.0.0.1' 或 'u'@'localhost'——这时候报的错是 Access denied，根本不会提示插件或 host 不对。
