MySQL 默认账户与空密码是最大风险源
新装 MySQL 后，
root@localhost账户默认可能无密码，或存在
root@127.0.0.1、
root@::1等多个同名但主机不同的账户，部分甚至密码为空。攻击者只要能本地登录（比如通过 SSH 进入服务器），就能直接
mysql -u root无密进入，完全控制数据库。 立即运行
SELECT user, host, authentication_string FROM mysql.user;查看所有账户及其认证字符串（MySQL 5.7+）或
password字段（5.6 及更早） 对所有空密码账户（
authentication_string为
''或
*），用
ALTER USER 'user'@'host' IDENTIFIED BY '强密码';重置 删除无用账户：如
DROP USER 'root'@'%';（除非明确需要远程 root）、
DROP USER ''@'localhost';（匿名用户） 禁止 root 远程登录：保留
root@localhost，删掉或禁用
root@'%'和其他通配 host
密码策略必须启用并强制执行
MySQL 5.7+ 自带
validate_password插件，但默认不启用。不启用时，
SET PASSWORD或
CREATE USER允许设
'123'、
'password'这类弱口令，等于形同虚设。 检查是否加载：
SHOW VARIABLES LIKE 'validate_password%';若返回空，说明插件未启用 启用插件：
INSTALL PLUGIN validate_password SONAME 'validate_password.so';（Linux）或
validate_password.dll（Windows） 设置强度等级：
SET GLOBAL validate_password.policy = MEDIUM;（推荐），同时设最小长度：
SET GLOBAL validate_password.length = 10;策略生效后，
CREATE USER 'app'@'%' IDENTIFIED BY 'abc';会报错
ERROR 1819 (HY000): Your password does not satisfy the current policy requirements
应用连接不要复用 root，要按需建最小权限账号
很多 Web 应用直接在配置里写
root和密码，一旦代码泄露、日志误打、或 SQL 注入成功，攻击者就拿到全库
DROP权限。真实场景中，一个订单查询接口只需要
SELECT权限，却给了
ALL PRIVILEGES。 创建专用账号：
CREATE USER 'shop_app'@'10.20.30.%' IDENTIFIED BY '长随机密码';（限定来源 IP 段） 只授必要权限：
GRANT SELECT, INSERT ON shop_db.orders TO 'shop_app'@'10.20.30.%';，不要用
ON *.*回收多余权限：
REVOKE DROP ON shop_db.* FROM 'shop_app'@'10.20.30.%';（即使没显式授予，也建议显式回收） 定期审计：
SELECT u.user, u.host, p.table_schema, p.privilege_type FROM mysql.users u JOIN mysql.schema_privileges p ON u.user = p.grantee;（注意：不同版本视图名略有差异）
网络层暴露和错误信息泄露常被忽视
MySQL 默认监听
0.0.0.0:3306，意味着只要防火墙没拦，外网就能扫到端口。而开启
log_error_verbosity = 3（默认）时，错误日志会记录认证失败的用户名——攻击者可借此枚举有效账户名。 绑定内网地址：修改
my.cnf中
bind-address = 127.0.0.1或具体内网 IP（如
10.20.30.5），避免
0.0.0.0关闭远程 root 登录后，仍要确认防火墙规则：
ufw deny 3306或
iptables -A INPUT -p tcp --dport 3306 -j DROP降低错误日志敏感度：
SET GLOBAL log_error_verbosity = 2;（不记录用户名，只记失败事件） 禁用旧协议认证：
SET GLOBAL old_passwords = 0;，并确保客户端使用
caching_sha2_password或
mysql_native_password插件
实际中最容易被忽略的是：多个 host 的同名账户权限不一致，且其中一个留着空密码；或者以为禁用了 root@’%’ 就安全了，却忘了 root@’::1’ 依然可用。这类细节不会报错，也不会告警，但只要一次扫描或一次本地提权，就全线失守。
