MySQL通用查询日志默认关闭，需先执行SHOW VARIABLES LIKE 'general_log%'确认状态；开启后宜设log_output='TABLE'并动态启用，避免磁盘爆满；分析时应聚焦SQL结构异常、编码字符、高频相似语句等注入痕迹，结合grep/awk快速筛选，而非人工遍历。
查 general_log 前先确认它是否真在记录
MySQL 默认关闭通用查询日志，直接去翻 /var/lib/mysql/hostname.log 或执行 SELECT * FROM mysql.general_log 很可能一无所获。必须先检查状态：SHOW VARIABLES LIKE 'general_log%' —— 如果 general_log 是 OFF，那日志根本没写，后续所有分析都是空谈。
开启它需要权限和重启（或动态设置），但生产环境通常禁用：日志体积爆炸、I/O 压力大、敏感 SQL 明文落盘。所以别指望总有现成日志可用；更现实的路径是——只在怀疑时段临时开启，且限定输出到表（general_log_file 设为空字符串，log_output='TABLE'），避免刷爆磁盘。
-
SET GLOBAL general_log = ON动态生效，但 MySQL 重启后失效 - 写入
mysql.general_log表比写文件稍安全，但表无索引，SELECT大量日志时极慢 - PostgreSQL 用户对应看
log_statement = 'all'+log_directory下的 CSV 日志，不是pg_stat_statements
从日志里识别可疑 SQL 模式，别只盯单引号
攻击者早就不手敲 ' OR 1=1 -- 了。真正该扫的是参数位置异常、语法结构断裂、高频非常规操作组合。比如一条本该带 WHERE user_id = ? 的查询，日志里却出现 WHERE user_id = 123 OR 1=1 UNION SELECT password FROM users —— 这种“参数值里含完整子句”才是强信号。
注意这些典型痕迹：
- SQL 中出现非业务预期的
UNION、SELECT ... FROM information_schema、LOAD_FILE(、SLEEP( - 同一客户端 IP 在几秒内连续执行多条结构相似但参数剧烈变化的语句（如
id=1→id=1 AND SLEEP(5)） - 字符串参数里含大量编码字符：
%27（'）、%3B（;）、%23（#），尤其出现在 URL query string 对应的 SQL 字段中 - 日志中
argument列（MySQL 表日志）或statement字段里，值以单引号开头却未闭合，或中间有嵌套引号
用 grep 和 awk 快速筛日志，别硬读
日志文件动辄 GB 级，人工翻等于放弃。Linux 下最有效的是组合命令直击要害：
grep -i "union\|information_schema\|load_file\|sleep(" /var/log/mysql/general.log | head -20但要注意路径和权限：mysqld 写日志用的是运行用户（常为 mysql），普通用户 cat 不了，得 sudo 或让 DBA 导出片段。另外，日志格式影响正则效果：
- MySQL 文件日志默认每行一条，含时间戳+线程ID+语句，适合
grep - PostgreSQL CSV 日志需先用
cut -d',' -f5提取第五列（statement字段），再过滤 - 避免用
.*匹配跨行内容——SQL 日志基本不换行，跨行意味着解析错误或日志截断，本身已是异常
发现痕迹后，别急着删日志或封 IP
日志是证据链起点，不是终点。一条疑似注入的 SELECT ... FROM users WHERE name = 'admin' -- ' 只说明应用层未过滤输入，但无法判断是否真拿到数据——要看后续有没有 INSERT INTO attacker_log 或外连 DNSLog 的行为。
更关键的是定位漏洞点：
- 查这条 SQL 对应的应用代码路径：是
userController.php第 42 行拼接的？还是 ORM 的whereRaw()调用？ - 对比正常请求和恶意请求的 HTTP 请求头、Referer、User-Agent —— 自动化工具（如 sqlmap）常暴露特征，而手工测试可能混在真实流量里
- 如果日志里只有成功语句，没有报错，说明 WAF 或应用已静默拦截，此时要同步查
error_log和应用层异常监控
真正难的从来不是“找到痕迹”，而是把日志里一行 SQL 和线上某个 commit、某个配置变更、某个第三方组件升级关联起来——这一步没上下文，纯靠猜。
