必须禁用 root@'%' 并限制 root 仅限 localhost 或内网 ip；应用应使用最小权限专用账号，密码由密钥服务注入，禁止硬编码 root 连接串；日常运维禁用 root，高危操作需离线高权账号。
因为 root 账号拥有 ALL PRIVILEGES，一旦被攻击或误操作，整个数据库就没了——不是“可能出问题”，而是“必然失守”。
root@'%' 是最危险的登录入口
很多团队删了 root 但忘了查 Host 字段。只要存在 'root'@'%'，攻击者就能从任意 IP 尝试爆破。它不依赖防火墙是否开启，也不怕 DNS 绕过，是等保三级明确要求禁用的配置。
- 执行
SELECT User, Host FROM mysql.user WHERE User = 'root';确认是否存在通配符 host - 发现
'root'@'%'必须立刻DROP USER 'root'@'%';，再FLUSH PRIVILEGES; - 保留的 root 实例只应是
'root'@'localhost'（Unix socket）或严格限定的内网 IP，如'root'@'10.0.1.5'
应用连接用 root = 把密码贴在数据库门上
应用配置里写 mysql://root:xxx@db-host/，等于把主库钥匙塞进每个服务容器、每份日志、每次 git commit。一旦镜像泄露或配置误传，攻击者直接连库执行 DROP DATABASE。
- 必须为每个业务模块创建专用账号，例如
'order_app'@'10.20.30.%' - 授权只到具体库：用
GRANT SELECT, INSERT ON order_db.*，绝不用ON *.* - 密码禁止硬编码，必须由密钥服务（如 Vault）注入环境变量，且连接字符串中不能出现
root字样
权限过大导致误操作无法挽回
root 能执行 SHUTDOWN、DROP USER、ALTER TABLE ... RENAME TO，这些操作没有回收站，也没有事务回滚。一个没加 WHERE 的 UPDATE 就能清空用户表。
- 日常运维不要用 root 登录，DBA 应使用离线保管的专用高权账号，如
'dba_backdoor'@'localhost' - 备份脚本、监控工具、定时任务也必须用最小权限账号，例如只授
SELECT+LOCK TABLES+RELOAD -
GRANT OPTION是权限扩散起点，除非真要授权他人建账号，否则一律禁用
真正难的不是“怎么删 root”，而是让每个服务都用对账号、每个 SQL 都跑在权限边界内——这需要开发、运维、安全三方在部署前就对齐权限矩阵，而不是上线后再补救。
