慢查询日志中可通过高频出现UNION SELECT、LOAD_FILE()、information_schema.tables等高开销关键词识别注入痕迹，需结合PROCESSLIST实时抓取、EXPLAIN分析执行计划异常及多日志交叉验证权限行为。
怎么看慢查询日志里有没有注入痕迹
慢日志本身不记“快”的恶意语句，但攻击者扫库、爆表、导数据时经常用 UNION SELECT、LOAD_FILE()、SELECT ... FROM mysql.user 这类高开销操作——它们未必超慢查询阈值，但一旦高频出现，就是强信号。
先确认慢日志是否开启：SHOW VARIABLES LIKE 'slow_query_log'；若为 OFF，临时打开：SET GLOBAL slow_query_log = 'ON'（注意：重启失效，需改配置文件）。
查完记得关，避免磁盘撑爆：SET GLOBAL slow_query_log = 'OFF'。
- 重点搜这些关键词：
UNION SELECT、information_schema.tables、extractvalue(、updatexml(、floor(rand(0)、SLEEP( - 别只看
query_time > 1的条目，加个ORDER BY start_time DESC LIMIT 100看最近高频语句 - 注意路径权限：
SHOW VARIABLES LIKE 'slow_query_log_file'返回的路径，得确保你有读权限，否则日志写了也看不到
怎么从 processlist 抓正在执行的可疑 SQL
SHOW PROCESSLIST 是入侵发生时最直接的“现场快照”，尤其适合抓堆叠注入（; 分隔多语句）、写马、删库等正在跑的危险操作。
它比慢日志更实时，但默认只显示本用户连接；想看全部，得用 root 或有 PROCESS 权限的账号登录。
- 快速过滤可疑项：
SELECT * FROM information_schema.PROCESSLIST WHERE INFO IS NOT NULL AND (INFO LIKE '%union%' OR INFO LIKE '%sleep(%' OR INFO LIKE '%load_file%' OR INFO LIKE '%into outfile%') ORDER BY TIME DESC; - 留意
TIME值特别大（比如 > 60 秒）且STATE是Sending data或Copying to tmp table的长连——可能是大数据导出或爆破 - 别忽略空
USER或HOST为%的连接，结合FROM列 IP 反查是否异常
EXPLAIN 能不能帮判断是不是注入语句
不能直接判断，但能暴露注入后留下的“设计缺陷”：比如原本走索引的查询，突然变成 type: ALL（全表扫描），说明 WHERE 条件被绕过或篡改了。
典型场景是：攻击者用 id=1 OR 1=1 注入后，MySQL 优化器无法使用索引，导致性能断崖式下跌——这时 EXPLAIN 就成了佐证依据。
- 对疑似被注入的接口 SQL，手动执行
EXPLAIN FORMAT=TRADITIONAL SELECT ...，对比正常请求的执行计划 - 重点看：
key是否为NULL、rows是否暴增、Extra是否含Using where; Using filesort等低效标记 - 注意：MySQL 8.0+ 的
FORMAT=TREE更直观，但某些旧监控工具不兼容，别在自动化脚本里硬切
为什么光看日志不够，还得交叉验证
因为攻击者会清日志、关通用日志、用合法账号做坏事——单点日志很容易被绕过或伪造。
真正有效的排查，是把 general_log（如果开着）、slow_query_log、error_log、系统 /var/log/auth.log 和 PROCESSLIST 四条线的时间戳对齐，找重合点。
- 例如：
error_log里有DROP TABLE users记录，时间戳是2026-03-17 22:15:03；立刻去general_log查同一秒前后 5 秒的Connect和Query，就能锁定源头 IP 和账号 - 再查
mysql.user表，看那个账号是不是新创建的、Host 是不是%、有没有FILE权限——这三者同时存在，基本就是后门 - 最容易被忽略的是：攻击者可能用已有的业务账号注入，此时权限检查比日志分析更重要
日志只是线索，权限和行为才是证据链的锚点。
