为什么MySQL建议不要在生产环境中使用root账号运行业务？

必须禁用 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 都跑在权限边界内——这需要开发、运维、安全三方在部署前就对齐权限矩阵，而不是上线后再补救。