直接update mysql.user表会失败，因mysql 5.7+中该表为视图，执行将报error 1356；必须用rename user逐host安全重命名，并验证权限、插件及下游配置。
直接 UPDATE mysql.user 表会失败，别试
MySQL 5.7+ 版本里 mysql.user 不是普通表，而是视图，底层关联 mysql.global_priv 等系统表。执行类似 UPDATE mysql.user SET User = 'admin' WHERE User = 'root' 会立刻报错：ERROR 1356 (HY000): View 'mysql.user' references invalid table(s) or column(s)。更严重的是，硬改可能破坏元数据一致性，导致实例无法启动。
必须用 RENAME USER，且要逐 host 处理
RENAME USER 是 MySQL 官方唯一支持、原子且安全的重命名方式。它同步更新权限、认证信息和内部缓存，不需重启服务，也不用手动 FLUSH PRIVILEGES（虽然显式执行更稳妥）。
- 先查清所有 root 账号的完整形式：
SELECT User, Host FROM mysql.user WHERE User = 'root';—— 常见的有'root'@'localhost'、'root'@'127.0.0.1'、'root'@'%'，每个都得单独处理 - 逐条执行重命名：
RENAME USER 'root'@'localhost' TO 'admin'@'localhost'; - 操作完立刻验证：
SHOW GRANTS FOR 'admin'@'localhost';确保SUPER、GRANT OPTION等关键权限仍在
重命名后连不上？大概率是 host 或 plugin 问题
不是名字改错了，而是连接时被认证插件或 host 匹配拦住了：
-
RENAME USER不改变原账号的plugin字段（如caching_sha2_password），但某些老客户端（比如旧版 MySQL Workbench）会因插件名不匹配拒绝握手 - host 必须完全一致：你只改了
'root'@'%'，但应用连的是'root'@'192.168.1.100'，这个账号还存在且没动，就会“以为改了却没生效” - 检查是否有同名冲突：
'admin'@'localhost'如果原本就存在，RENAME USER会直接报错，得先DROP USER 'admin'@'localhost';
别忘了配套更新运维脚本和监控配置
很多自动化工具（Ansible playbook、Zabbix 监控项、备份脚本）会硬编码 root 用户名。改名后它们会静默失败，而不是报错——这类问题往往在半夜告警才暴露。
- 生产环境操作前，务必备份当前用户状态：
SELECT * FROM mysql.user INTO OUTFILE '/tmp/user_pre_rename.csv'; - 低峰期执行，操作后立即测试所有依赖该账号的链路：备份任务、CI/CD 数据库初始化、APM 连接池探活
- 如果用了 Vault 或其他密钥管理工具，确认其存储的用户名字段也已同步更新
真正容易被忽略的点在于：重命名本身很快，但下游系统对用户名的强依赖比你想象中更广泛、更隐蔽。一次 RENAME USER 后，最耗时的往往不是数据库操作，而是排查哪个监控指标突然不更新了。
