业务系统直连mysql root账号是生产环境明确红线，因其导致sql注入或配置泄露即可引发全库不可逆损毁；root权限无回收站机制，误操作如drop database秒级生效且无法回滚，共享账号更使审计溯源失效，必须按最小权限原则创建专用账号并彻底清理所有root远程访问及硬编码连接串。
业务系统直连 MySQL root 账号不是“不推荐”，而是生产环境的明确红线——它会让一次 SQL 注入、一次配置泄露或一个手滑命令，直接变成全库不可逆损毁。
误操作风险：权限越大，容错越低
MySQL 没有回收站，DROP DATABASE、TRUNCATE TABLE、ALTER USER 这类语句在 root 权限下秒级生效且无法回滚。而业务代码里一个没加 WHERE 的 UPDATE 或拼接错误的动态 SQL，在普通账号下顶多报错，在 root 下就是批量覆写。
- 应用日志里出现
Access denied for user 'root'@'192.168.x.x'？大概率是有人正在暴力扫这个口子 - 监控告警显示
Queries_per_second突增，但业务无变更？可能已有攻击者用root执行了全表导出 - 备份脚本用
root连接 +mysqldump --all-databases？一旦密码泄露，所有库数据一并打包带走
权限模型失灵：审计和隔离彻底失效
MySQL 的用户是 'user'@'host' 二元组合，root 共享账号意味着：SELECT User, Host FROM mysql.user WHERE User = 'root' 查出来可能是 root@localhost、root@10.10.5.%、root@% 多条记录，但日志里只记用户名，根本分不清哪条 DELETE 是哪个服务发起的。
- 线上数据被改错，DBA 查
general_log只看到一堆root操作，排查周期从分钟级拉长到小时级 - 开发、测试、运维共用一个
root密码，离职交接时没人知道谁动过哪些表结构 - 安全扫描报告标红 “高危：存在未授权访问路径”，实际根源是
root@%还开着
MySQL 8.0+ 的权限校验更严格，root 不再“万能”
新版 MySQL 强制通过 CREATE USER 和 GRANT 管理权限，直接 UPDATE mysql.user 表不仅无效，重启后还会丢失。而很多团队还在用老思维给 root 加限制（比如删掉 FILE 权限），结果发现 SHOW GRANTS FOR 'root'@'localhost' 返回空——因为权限字段已被系统忽略，校验逻辑已下沉到插件层。
-
root@localhost默认带SUPER、FILE、PROCESS，但备份只需RELOAD+LOCK TABLES+ 库级SELECT - 想禁用远程
root？不能只靠防火墙，必须执行DROP USER 'root'@'%'，否则FLUSH PRIVILEGES后仍可能残留缓存 - 用
mysql_secure_installation只能删掉匿名用户和测试库，它不会碰root@%，这步必须手动做
真正难的不是建个新账号，而是把散落在配置文件、Shell 脚本、Docker Compose、CI/CD 流水线里的所有 root 连接串全部找出来、替换掉、验证通——漏掉任意一个，加固就等于白做。
