MySQL general_log 无新语句因log_output为'NONE'或旧连接未生效；PostgreSQL pg_audit参数显示?因pgaudit.log_parameter=off；SQL Server堆叠注入需匹配分号+多语句结构及上下文可疑组合。
MySQL general_log 里查不到新语句？先确认 log_output 和连接状态
执行了 SET GLOBAL general_log = ON 却在 mysql.general_log 里看不到任何新记录，大概率卡在这两个地方：
-
log_output还是'NONE'：必须显式设为'TABLE'或'FILE'，只开general_log不生效 - 已有连接不受影响：日志开关只对新建连接生效，老连接的请求不会进日志，得用新会话复现请求才能捕获
实操建议：先查状态 SELECT @@global.general_log, @@global.log_output;；再设 SET GLOBAL log_output = 'TABLE'; SET GLOBAL general_log = ON;；查时加时间范围和 LIMIT：SELECT * FROM mysql.general_log WHERE event_time > NOW() - INTERVAL 5 MINUTE AND argument REGEXP "[[:space:]]*union[[:space:]]+select|sleep\(|benchmark\(" LIMIT 100;
PostgreSQL pg_audit 日志里参数全是 ?，怎么看到真实 payload
开了 pg_audit 却只看到 WHERE id = ? 这种占位符，实际攻击 payload（如 WHERE id = 1 OR 1=1）完全不可见——这是默认配置导致的脱敏行为。
-
pgaudit.log_parameter = off（默认值）：所有绑定参数都以占位符形式记录，攻击 payload 不可见 -
pgaudit.log_catalog = on（默认值）：大量SELECT * FROM pg_class类系统表访问刷屏，业务 SQL 被淹没
实操建议：在 postgresql.conf 中明确设置：pgaudit.log = 'read, write, ddl'、pgaudit.log_parameter = on、pgaudit.log_catalog = off，改完必须重启 PostgreSQL 才生效。
SQL Server 审计日志里识别堆叠注入，关键看分号+多语句结构
堆叠注入（stacked query）不像联合查询那样有明显回显，但会在审计日志中留下「分号 + 多条语句」的结构特征，比如 ; 后紧跟 SELECT、INSERT、DROP、EXEC 等关键词。
- 必须过滤
BATCH_STARTED/EXECUTE类事件，避免把存储过程调用误判为攻击 - 低权限账号执行高危操作（如
EXEC xp_cmdshell）比高权限账号更可疑 - 单条日志中出现多个
;分隔的语句，且第二条开始含非常规关键字（如WAITFOR DELAY、sp_addsrvrolemember），置信度极高
实操建议：用 T-SQL 查询 sys.fn_get_audit_file，匹配 statement LIKE '%;[^;]*SELECT%' 或 statement LIKE '%;[^;]*(DROP|EXEC|DECLARE)%'，并关联 server_principal_name 和 database_name 做上下文过滤。
别只扫 “union”“select”，重点匹配语法异常 + 上下文可疑组合
业务 SQL 本身就有大量合法 UNION SELECT，光靠关键词匹配漏报率高、误报爆炸。真正该抓的是「语法异常 + 上下文可疑」组合：
-
OR\s+1\s*=\s*1出现在单引号闭合后，例如id='1' OR 1=1或name='a'' OR ''x''=''x' -
UPDATEXML\(|EXTRACTVALUE\(|FLOOR\(RAND\(0\)，括号间允许空格或换行，正则要加\s* - 语句末尾带
;--或;#，且前面不是CREATE PROCEDURE等合法多语句场景
容易踩的坑：没过滤系统账号（如 root@localhost）或内部中间件账号，导致告警被刷屏；把 SELECT * FROM mysql.user 当成攻击，其实可能是 DBA 在查权限——得结合 user_host 和频次判断。
