直接修改 mysql.user 表会出错，因其在5.7+版本中是视图；应使用 RENAME USER 安全重命名，需逐个处理不同 host 的账号，注意认证插件兼容性、权限继承及自动化工具配置更新。

直接改 mysql.user 表会出事

想用 UPDATE 语句直接修改 mysql.user 表里的用户名？这个念头得赶紧打住。即便你手握 root 权限，执行后也会立刻收到报错：ERROR 1356 (HY000): View 'mysql.user' references invalid table(s) or column(s)。问题出在哪儿？从 MySQL 5.7 版本开始，mysql.user 已经不再是一张普通的表，而是一个视图。它的底层关联着 mysql.global_priv 等系统表。如果强行修改，很可能会破坏元数据的一致性，严重时甚至导致数据库实例无法正常启动。

正确做法：用 RENAME USER

那么，安全的方法是什么？答案是使用 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';
• 操作完成后，虽然 RENAME USER 通常会自动生效，但为了万无一失，建议显式执行一次：FLUSH PRIVILEGES;

重命名后连不上？检查 host 和认证插件

执行完重命名，如果发现新的账号无法连接，问题往往不在改名本身，而在于以下几个容易被忽略的细节：

• 认证插件兼容性：RENAME USER 会保留原账号的密码哈希和认证插件设置。但如果客户端工具（例如某些旧版的 MySQL Workbench）不支持新的默认插件（如 caching_sha2_password），就会导致连接失败。
• Host 匹配问题：重命名时，必须覆盖所有需要修改的 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 会直接报错，你需要先处理掉这个冲突账号。
• 做好安全备份：在生产环境操作前，建议在业务低峰期进行，并先备份一份用户信息：SELECT * FROM mysql.user INTO OUTFILE '/tmp/user_pre_rename.csv';

说到底，重命名操作本身执行很快，但后续的权限完整性验证、客户端适配以及整个工具链的检查，才是确保平稳过渡的关键，也是最容易出纰漏的环节。