mysql root@'%' 是最大安全隐患，应立即删除并禁用远程root；root权限过大易致误操作，须按最小权限原则创建专用账号；权限丢失时需跳过权限表启动恢复；配置层加固需绑定本地地址、启用密码校验并删除匿名用户。
root@'%' 远程登录是最大安全隐患
MySQL 的 root 用户一旦允许从任意主机登录（即存在 'root'@'%'），就等于把数据库的“总钥匙”扔在公网门口。暴力破解、自动化扫描、弱口令爆破——所有攻击链的第一步都瞄准它。这不是理论风险，而是每天真实发生的入侵入口。
- 检查是否存在该账户：
SELECT User, Host FROM mysql.user WHERE User = 'root';
- 若结果中含
'root'@'%'，应立即删除：<pre class="brush:php;toolbar:false;">DROP USER 'root'@'%';</pre> - 注意：删除后必须执行
FLUSH PRIVILEGES; 才生效，否则权限表缓存仍可能让旧规则残留 - 别试图“改 host 为具体 IP”来保留远程 root——IP 可伪造、防火墙可能失效，最小权限原则下，root 就不该走网络
root 权限过大导致误操作不可逆
拥有 ALL PRIVILEGES 意味着能 DROP DATABASE、TRUNCATE TABLE、REVOKE 任何用户权限，甚至 SHUTDOWN 实例。日常运维中一个手抖或脚本 bug，就可能清空生产库，且无回收站机制。
- 典型误操作场景：用 root 执行未加
WHERE条件的UPDATE或DELETE；误删mysql系统库表；误执行DROP USER清空所有账号 - 解决思路不是“更小心”，而是“没权限就不能干”：创建专用账号，例如备份只给
SELECT, LOCK TABLES, RELOAD；应用只给SELECT, INSERT, UPDATE；DBA 日常用admin账号，显式授予权限而非ALL - 切记：不要给普通管理账号加
GRANT OPTION，除非真需要授权他人——这是权限扩散的起点
权限丢失时别硬刚，先确认是否跳过权限表启动
当发现 root@localhost 登录后无法执行 GRANT、USE mysql 或提示 Access denied，大概率是权限字段被意外清空（比如误执行了 UPDATE mysql.user SET ...），而不是密码错了。
- 验证方式：
SHOW GRANTS FOR 'root'@'localhost';—— 若返回空或只有极少数权限，说明权限已丢失 - 恢复关键步骤：停止 MySQL，用
mysqld_safe --skip-grant-tables &启动，再进库执行UPDATE mysql.user SET Grant_priv='Y', Super_priv='Y' WHERE User='root' AND Host='localhost';，最后FLUSH PRIVILEGES; - 坑点：MySQL 5.7+ 使用
authentication_string字段存密码，8.0+ 默认禁用PASSWORD()函数，直接UPDATE密码字段会失败，必须用ALTER USER
配置层加固比权限语句更重要
光删掉 'root'@'%' 不够，如果 MySQL 还监听 0.0.0.0:3306，攻击者仍可能通过其他高危账号（如弱密码的 admin）提权，或利用未修复漏洞绕过权限检查。
- 在
my.cnf中强制绑定本地：bind-address = 127.0.0.1（比skip-networking更实用，保留 socket 访问） - 启用密码强度校验：
INSTALL PLUGIN validate_password SONAME 'validate_password.so';，再设策略：SET GLOBAL validate_password.policy = MEDIUM; - 删除匿名用户：
DROP USER ''@'localhost';，这类账户常被忽略，但可能被用于绕过认证
最常被忽略的一点：权限变更后不检查 Host 字段的大小写和通配符细节。比如 'root'@'LOCALHOST' 和 'root'@'localhost' 是两个不同用户，'app'@'192.168.%' 可能意外匹配到不该访问的网段——权限审计必须连同 host 字符串一起看。
