不能仅靠long_query_time防DoS，真实攻击藏在无索引SELECT*或高频SLEEP(1)等合法低效SQL中；需三步验证慢查询日志是否真启用，并用shell命令快速筛查攻击特征，结合Threads_running、PROCESSLIST和错误日志交叉判断，再通过iptables或ProxySQL限制连接速率，构建多层防御闭环。
不能只靠 long_query_time 拦慢查询，更不能指望它防 DoS —— 真实攻击藏在“合法但低效”的 SQL 里，比如无索引的 SELECT * 或高频 SLEEP(1) 探测，它们不触发连接数限制，却能拖垮 CPU 和 IO。
确认慢查询日志是否真在记录，而不是配置假开关
很多人改了 slow_query_log = 1 就以为万事大吉，结果日志根本没写。必须三步验证：
- 执行
SHOW VARIABLES LIKE 'slow_query_log';，返回值必须是ON（不是1或TRUE） - 查路径：
SHOW VARIABLES LIKE 'slow_query_log_file';，然后ls -l看文件是否存在、MySQL 用户是否有写权限（父目录也得有写权限） - 手动触发测试：
SELECT SLEEP(2);（前提是long_query_time ≤ 2），再tail -n 1 /var/log/mysql/mysql-slow.log确认新增
常见失效点：配置改了没重启 mysqld；log_output 被设为 TABLE（此时日志进 mysql.slow_log 表，不是文件）；日志路径父目录不存在。
用 shell 命令快速筛出攻击特征，别人工翻日志
攻击者不会等你打开日志文件慢慢看。直接用命令抓高频、集中、低质量线索：
- 抓高频语句模式：
awk '/^# Time/ {if (sql) print sql | "sort | uniq -c | sort -nr"; sql=""} !/^#/ && !/^$/ {sql = sql $0} END {print sql | "sort | uniq -c | sort -nr"}' /var/log/mysql/mysql-slow.log | head -10 - 查某 IP 出现次数（需日志含
# User@Host）：grep -A 1 'User@Host' /var/log/mysql/mysql-slow.log | grep '192.168.1.100' | wc -l - 找“快但无索引”的隐患（依赖
log_queries_not_using_indexes = 1）：grep -A 2 'No_index_used' /var/log/mysql/mysql-slow.log | grep -B 1 'Query_time'
注意：若日志被 logrotate 压缩过，把 grep 换成 zgrep；mysqldumpslow 默认按平均耗时排序，容易漏掉频次高但单次不长的探测型语句。
交叉验证三个信号，才能判断是攻击不是业务抖动
孤立的慢查询可能是业务问题；但以下任一组合出现，就得立刻响应：
-
SHOW STATUS LIKE 'Threads_running';在慢查询高峰时持续 > 50 —— 说明不是排队，而是并发执行卡死，CPU/IO 已打满 -
SHOW PROCESSLIST;中大量状态为Sending data或Copying to tmp table，且Host字段指向同一网段或相同 IP - 错误日志（
log_error文件）里同期出现密集的Access denied for user记录 —— 很可能在爆破，不是单纯慢查询
特别注意：Threads_running 高 + Aborted_connects 突增，往往意味着 max_connect_errors 被误触发，host_cache 被污染，需要清空或调高阈值，而不是加连接数。
光杀慢查询不够，得从连接源头压住新建速率
恶意短连接洪峰（建连即断）能让 max_connections 彻底失效。真正要控的是单位时间内的新建连接数：
- 系统层限速（最有效）：
iptables -A INPUT -p tcp --dport 3306 -m connlimit --connlimit-above 3 --connlimit-mask 32 -j DROP（每秒同一 IP 最多 3 个新连接） - 代理层限流（如 ProxySQL）：在
mysql_query_rules中限制某用户每秒最多执行 5 次SELECT，比 MySQL 原生max_user_connections更精准 - MySQL 自身调优：
wait_timeout设为 300–600 秒（太低会引发重连雪崩），同时监控Threads_connected和Aborted_connects
最后提醒一句：慢查询日志本身不记录攻击行为，它只是发现 DoS 风险最实用的入口。真正的防御闭环，必须把日志分析、连接控制、账号权限、网络隔离这几层串起来 —— 少一层，攻击者就有一条路可走。
