高危账户、弱密码、暴露接口和过度权限四类问题占mysql入侵事件87%以上；需执行select user,host from mysql.user where user='' or host='%'查隐患，删匿名用户和root@%，禁用with grant option及file等高危权限，验证bind-address与防火墙生效，启用validate_password强策略，并确保flush privileges与服务重启闭环。
直接查出高危账户、弱密码、暴露接口和过度权限——这四类问题占生产环境MySQL入侵事件的87%以上，不用等扫描工具，5分钟内就能人工定位。
查匿名用户和root@%这类危险账户
MySQL默认安装常留空用户名或开放root远程访问，这是最易被利用的入口。别只看SELECT user, host FROM mysql.user，要加条件过滤：
-
SELECT user, host FROM mysql.user WHERE user = '' OR host = '%'—— 一眼揪出隐患 - 发现
''@'localhost'或'root'@'%'必须立刻删：DROP USER ''@'localhost'; DROP USER 'root'@'%'; - 删之前确认至少保留一个强认证本地root：
'root'@'127.0.0.1'或'root'@'::1'，否则可能锁死
检查业务账号是否开了WITH GRANT OPTION
这个选项等于给普通账号发了“再授权许可证”，一旦泄露，攻击者能自建子账号绕过审计。用SHOW GRANTS逐个验证比查mysql.db表更准：
-
SHOW GRANTS FOR 'app_user'@'192.168.1.%';—— 注意输出里是否含WITH GRANT OPTION - 只要没明确需要委派权限，一律回收：
REVOKE GRANT OPTION ON *.* FROM 'app_user'@'192.168.1.%'; - 特别警惕
FILE、PROCESS、SUPER权限，业务账号几乎不需要，REVOKE FILE ON *.* FROM ...直接干掉
验证bind-address和防火墙是否真正生效
很多人改了my.cnf里的bind-address = 127.0.0.1就以为安全了，但实际监听状态可能没更新：
- 运行
netstat -tulnp | grep :3306，确认输出中是127.0.0.1:3306而非*:3306（后者=监听所有IP） - 即使绑定了
127.0.0.1，也要配防火墙规则：iptables -A INPUT -p tcp --dport 3306 -j DROP防误开 - 云环境务必检查安全组——配置文件改对了，但安全组放通
0.0.0.0/0，等于裸奔
看validate_password插件是否真在起作用
插件开着≠策略生效。很多团队只执行INSTALL PLUGIN validate_password SONAME 'validate_password.so';，却没调参数：
-
SHOW VARIABLES LIKE 'validate_password%';—— 关键看validate_password.length是否≥12，validate_password.policy是否为MEDIUM或STRONG - 查密码是否明文存储：
SELECT user, host, plugin FROM mysql.user WHERE plugin = 'mysql_native_password' AND authentication_string LIKE '$2y%';（bcrypt格式才安全） - 空密码账号用
ALTER USER 'test'@'%' IDENTIFIED WITH caching_sha2_password BY 'NewPass!2026';重置，别用SET PASSWORD旧语法
真正容易被忽略的是：权限回收后不执行FLUSH PRIVILEGES，或者改完my.cnf没重启MySQL服务——配置写了等于没写。风险点不在多，而在这些动作是否闭环。
