频繁出现“Access denied”错误日志、SHOW PROCESSLIST显示大量Connect状态未认证连接、系统层TCP半连接与CPU异常波动，是MySQL正在遭受暴力破解的三大核心信号。
MySQL错误日志里频繁出现 Access denied for user
这是最直接的信号。MySQL默认会把登录失败记录进错误日志（路径通常是 /var/log/mysql/error.log 或 /var/lib/mysql/hostname.err），只要启用了 log_error_verbosity = 3（MySQL 8.0+ 默认开启）。
执行：
grep "Access denied" /var/log/mysql/error.log | tail -n 100
如果1分钟内出现几十甚至上百条，且用户名、IP高度重复或呈现规律性变化（比如 admin、root、test 轮着试，密码字段为空或来自常见字典词），基本可判定正在被爆破。
注意：有些攻击者会伪造源IP，所以单看IP不准；重点看单位时间内的失败密度和用户名/密码组合的“字典感”。
SHOW PROCESSLIST 显示大量 Connect 状态的空闲连接
攻击工具（如 Hydra、Metasploit 的 mysql_login）在爆破时通常不真正登录成功，而是在认证阶段就断开，但 MySQL 仍会短暂创建连接线程。
运行：
SHOW PROCESSLIST;
观察 Command 列是否大量为 Connect，State 为空或 Connecting to master 类似状态，且 User 为 unauthenticated user 或反复切换不同用户名。
如果同时看到几十个来自同一IP或不同IP但相同客户端版本（如 mysql_native_password）的连接，尤其在非业务高峰时段，就是典型爆破特征。
别只看当前连接数上限（max_connections），要看它们是否在几秒内集中涌进来又快速消失——这说明不是正常连接池行为。
系统层监控发现异常的网络连接与CPU波动
MySQL本身不暴露爆破节奏，但OS能反映负载突变。
用 ss -tn src :3306 | wc -l 或 netstat -an | grep :3306 | grep SYN_RECV | wc -l 查看瞬时TCP半连接数。爆破工具常并发建连，SYN包堆积明显升高。
同时观察：
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
top -b -n 1 | grep mysqld
如果 %CPU 在无查询前提下持续 >30%，且 mysqld 进程的 RES 内存稳定但线程数（Threads 列）飙升，大概率是认证逻辑在密集计算哈希（尤其启用了 caching_sha2_password 插件时更耗CPU）。
关键点：这种波动往往和应用日志里的慢查询无关，而是“认证密集型”负载——它不跑SQL，只卡在握手环节。
启用 mysqlauditlogin 或自定义触发器拦截高频失败
MySQL原生不提供登录失败计数，但可通过审计插件或简单脚本补位。
若已安装企业版审计插件，检查：
SELECT * FROM mysql.audit_log_summary_by_account WHERE failed_auths > 10;
社区版可临时用以下方式兜底：
- 在
mysqld配置中加log_warnings = 2（MySQL 5.7）或确保log_error_verbosity = 3（8.0+）已生效 - 用
awk实时解析错误日志，每分钟统计失败次数并告警：awk '/Access denied/{ip[$11]++} END{for (i in ip) if (ip[i]>20) print i, ip[i]}' /var/log/mysql/error.log - 禁用匿名用户、关闭远程
root、强制使用强密码策略——这些不能检测爆破，但能让爆破成功率趋近于零，比事后分析日志更有效
真正难防的是慢速、低频、多IP轮询的爆破，它会绕过基于阈值的规则。这时候得靠网络层WAF或数据库代理（如 ProxySQL）做连接指纹识别，而不是只盯MySQL自身日志。
