rename user 是唯一官方支持的用户重命名方式，但必须完整指定 'user'@'host' 格式，且不自动更新角色绑定、definer 和代理权限，认证插件可能回退，生产环境推荐“新建+迁移+切换+清理”四步法。
RENAME USER 是唯一官方支持的用户重命名方式，但它不是“改名”那么简单——它只替换用户名部分，host 字段必须显式保留且完全一致，否则语法报错或行为异常。
RENAME USER 必须写全 'user'@'host' 格式
MySQL 把 'user'@'host' 当作一个整体标识符，不能只写用户名。比如想把 'appuser'@'10.0.1.%' 改成 'apiuser'@'10.0.1.%'，下面这种写法会直接失败：
RENAME USER 'appuser'@'10.0.1.%' TO 'apiuser'; -- ❌ 缺少 host，报 ERROR 1396
正确写法是两边都带完整 host：
RENAME USER 'appuser'@'10.0.1.%' TO 'apiuser'@'10.0.1.%'; -- ✅
- 哪怕 host 是
'%'或'localhost'，也必须显式写出，不能省略 - 大小写敏感：MySQL 8.0+ 中
'ApiUser'@'localhost'和'apiuser'@'localhost'是两个不同账号 - 如果目标
'newuser'@'host'已存在，语句会报错，不会覆盖
权限不会自动迁移，但 grant 记录会“跟着走”
RENAME USER 执行后，mysql.db、mysql.tables_priv 等权限表里的 User 字段会被自动更新为新用户名——所以你执行 SHOW GRANTS FOR 'apiuser'@'10.0.1.%' 能看到原权限。
但注意这些例外：
-
mysql.role_edges不更新：如果旧用户被授予了角色（如GRANT 'developer' TO 'appuser'@'10.0.1.%'），重命名后角色绑定丢失，需手动GRANT 'developer' TO 'apiuser'@'10.0.1.%' -
mysql.proxies_priv不更新：代理权限（PROXY）需重新GRANT PROXY ON ... TO ... -
DEFINER值不变：存储过程、视图、事件里的DEFINER = 'appuser'@'10.0.1.%'不会自动改成新名，运行时可能报Access denied，得用ALTER PROCEDURE xxx SQL SECURITY DEFINER显式修正
MySQL 8.0+ 的认证插件陷阱
重命名不带 IDENTIFIED WITH 子句时，新用户可能回退到默认认证插件（如 caching_sha2_password → mysql_native_password），导致客户端连接失败。
尤其当旧用户用的是较新插件，而应用仍用老版 MySQL Connector/J 或 PHP mysqlnd 时，容易卡在密码验证环节。
- 查旧用户插件：
SELECT plugin FROM mysql.user WHERE user='appuser' AND host='10.0.1.%'; - 安全做法是重命名同时显式指定插件：
RENAME USER 'appuser'@'10.0.1.%' TO 'apiuser'@'10.0.1.%';<br>ALTER USER 'apiuser'@'10.0.1.%' IDENTIFIED WITH caching_sha2_password BY 'xxx';
- 复制环境要注意：GTID 模式下
RENAME USER是 DDL，会生成事务，若从库延迟高，可能阻塞复制线程
比 RENAME USER 更稳妥的替代路径
生产环境建议避开直接重命名，改用“新建 + 迁移 + 切换 + 清理”四步法：
- 用
SHOW GRANTS FOR 'appuser'@'10.0.1.%'导出权限语句 -
CREATE USER 'apiuser'@'10.0.1.%' IDENTIFIED WITH ...+GRANT ...复制全部权限（含角色、代理、SSL 选项等） - 切流量前，先用新用户连一次，确认能访问所有对象、触发器、函数都正常
- 确认无误后
DROP USER 'appuser'@'10.0.1.%'；别跳过这步，残留旧用户可能干扰审计或权限继承逻辑
真正麻烦的从来不是语法对不对，而是角色绑定、DEFINER、插件兼容性这些隐性依赖——它们不会报错，但会在某个凌晨三点让你收到告警。
