直接修改 mysql.user 表会出错，因其在5.7+版本中是视图；应使用 RENAME USER 安全重命名，需逐个处理不同 host 的账号，注意认证插件兼容性、权限继承及自动化工具配置更新。
直接改 mysql.user 表会出事
MySQL 不允许你用 UPDATE 直接修改 mysql.user 表里的 User 字段，哪怕你是 root。执行后会报错：ERROR 1356 (HY000): View 'mysql.user' references invalid table(s) or column(s) —— 因为 5.7+ 版本里 mysql.user 是个视图，底层对应 mysql.global_priv 和其他系统表，硬改会破坏元数据一致性，实例可能无法启动。
正确做法：用 RENAME USER
这是唯一被 MySQL 官方支持、原子且安全的重命名方式。它会同步更新权限、认证信息和内部缓存，不需要手动刷权限或重启服务。
操作步骤：
- 先确认当前 root 用户的完整账号形式（含 host）：
SELECT User, Host FROM mysql.user WHERE User = 'root'; - 假设有
'root'@'localhost'和'root'@'127.0.0.1'两个，必须分别重命名：RENAME USER 'root'@'localhost' TO 'admin'@'localhost'; - 再执行：
RENAME USER 'root'@'127.0.0.1' TO 'admin'@'127.0.0.1'; - 最后刷新权限：
FLUSH PRIVILEGES;（虽然RENAME USER内部已触发，但显式执行更稳妥）
重命名后连不上？检查 host 和认证插件
常见断连原因不是名字改错了，而是：
-
RENAME USER不会复制原用户的密码哈希或认证插件配置，新用户名沿用原记录的plugin和authentication_string，但某些客户端（如老版本 MySQL Workbench）会因 plugin 名称（如caching_sha2_password）不匹配而拒绝连接 - host 匹配变严格：比如你只重命名了
'root'@'%'，但应用连的是'root'@'192.168.1.100'，这个账号还存在且没动，就会造成“以为改了却没生效”的错觉 - 某些运维脚本或监控工具硬编码了
root用户名，改完后它们会失败，得同步更新配置
别忘了清理残留和验证权限继承
RENAME USER 不会自动迁移 mysql.db、mysql.tables_priv 等表中以旧用户名为条件的记录——但 root 的全局权限本来就不依赖这些表，所以一般不影响。真正要盯的是：
- 确认新用户是否仍有
SUPER、GRANT OPTION等关键权限：SHOW GRANTS FOR 'admin'@'localhost'; - 检查是否有其他同名用户（比如
'admin'@'localhost'原本就存在），RENAME USER会报错，必须先删掉冲突账号 - 生产环境建议在低峰期操作，并提前备份
mysql.user视图结果：SELECT * FROM mysql.user INTO OUTFILE '/tmp/user_pre_rename.csv';
重命名本身很快，但权限继承是否完整、客户端兼容性、自动化工具适配，才是最容易漏掉的环节。
