不能直接重命名MySQL的root用户，因其是内置超级用户，重命名会导致权限不一致、管理工具失效；应新建高权限账号并禁用root登录。
直接改 root 用户名会破坏 MySQL 系统权限模型
MySQL 的 root 不是普通账号，而是内置超级用户，其身份由 mysql.user 表中的 user 字段和认证插件共同绑定。直接用 RENAME USER 'root'@'localhost' TO 'admin'@'localhost' 虽语法合法，但后续可能触发：Access denied for user 'admin'@'localhost'、mysql_upgrade 失败、某些管理工具（如 MySQL Router、PMM）无法识别新名称。
安全替代方案：保留 root，新建高权限账号并禁用原登录方式
真正可控的做法是“绕开重命名”，转为权限接管 + 访问控制：
- 用
CREATE USER 'admin'@'localhost' IDENTIFIED BY 'strong_pass';新建账号 - 用
GRANT ALL PRIVILEGES ON *.* TO 'admin'@'localhost' WITH GRANT OPTION;赋权（注意：不加FLUSH PRIVILEGES，GRANT自动刷新） - 执行
UPDATE mysql.user SET authentication_string = '', plugin = 'auth_socket' WHERE User = 'root' AND Host = 'localhost';（仅限本地 Unix socket 登录场景），再FLUSH PRIVILEGES;使root无法密码登录 - 若需远程管理，把
'root'@'%'改为DROP USER 'root'@'%';，绝不留空密码或通配符账号
RENAME USER 的实际限制与风险点
该语句只改 mysql.user 表的 User 和 Host 字段，不更新其他系统表引用 —— 比如 mysql.proxies_priv、mysql.db 中仍存旧用户名，导致权限不一致。常见报错：ERROR 1396 (HY000): Operation RENAME USER failed，通常因目标账号已存在，或源账号不存在（大小写敏感，'ROOT' ≠ 'root'）。
示例陷阱：
RENAME USER 'root'@'127.0.0.1' TO 'dba'@'127.0.0.1'; -- 成功，但 'root'@'::1' 还在
结果是 IPv4 和 IPv6 下 root 仍可分别登录，没真正“替换”。
为什么不能删掉 root 账号
MySQL 8.0+ 的初始化逻辑依赖 root 存在；某些云托管服务（如 AWS RDS、阿里云 RDS）强制要求 root 账号不可删除，否则实例进入异常状态。更隐蔽的问题是：如果误删 root，又没提前配置好其他具备 SYSTEM_USER 权限的账号，将彻底失去管理员入口，只能靠重启跳过权限表（--skip-grant-tables）恢复 —— 这在生产环境基本不可行。
真正要做的，是让 root 失去所有登录能力，同时确保新账号有完整权限链，包括 BACKUP_ADMIN、CLONE_ADMIN（MySQL 8.0+）等新增特权。
