必须执行SHOW VARIABLES LIKE 'slow_query_log'确认返回ON，再检查slow_query_log_file路径权限、用SELECT SLEEP(2)测试写入，并通过tail验证日志新增；常见失效原因包括未重启mysqld、路径无写权限或log_output设为TABLE。
慢查询日志本身不记录攻击行为，但它是发现 DoS 风险最实用的入口——因为真实攻击往往藏在“合法但低效”的 SQL 里，比如同一 IP 短时间内刷出大量无索引的 SELECT *，而不是靠连接洪水。
怎么确认 slow_query_log 是否真在干活
别只看配置文件写了 slow_query_log = 1，得验证它实际在写日志：
- 执行
SHOW VARIABLES LIKE 'slow_query_log';，返回值必须是ON（不是1或TRUE） - 查日志路径：
SHOW VARIABLES LIKE 'slow_query_log_file';，然后ls -l看文件是否存在、有无写入权限 - 手动触发一条慢查询测试：
SELECT SLEEP(2);（前提是long_query_time≤ 2），再tail -n 1 /var/log/mysql/mysql-slow.log看是否新增记录
常见坑：配置改了没重启 mysqld；日志路径父目录不存在或 MySQL 用户无写权限；log_output 被设为 TABLE（此时日志写进 mysql.slow_log 表，不是文件）。
用命令快速筛出可疑慢查询模式
人工翻日志效率极低。直接用 shell 命令抓高频、集中、低质量线索：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 统计高频相似 SQL（去空格和换行后）：
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 默认按平均耗时排序，容易漏掉频次高但单次不长的探测型语句。
单看 slow.log 不够，必须交叉验证的三个信号
孤立的慢查询可能是业务问题；但以下任一组合出现，就该立刻拉响警报：
-
SHOW STATUS LIKE 'Threads_running';在慢查询高峰时持续 > 50 —— 说明不是排队，而是并发执行卡死，CPU/IO 已打满 -
SHOW PROCESSLIST;中大量状态为Sending data或Copying to tmp table，且Host字段指向同一网段或相同 IP - 错误日志（
log_error文件）里同期出现密集的Access denied for user记录 —— 很可能在爆破账号+试探 SQL 注入边界
真正危险的不是“慢”，而是“可批量复现的低质量查询”——它们消耗资源却不触发连接拒绝，让监控指标看起来“一切正常”，直到业务接口集体超时。
