mysql 8.0 的 audit_log 插件不能识别sql注入，仅记录元数据；需设为json格式才能获取sql_text，配合脚本筛查union、sleep()等特征，但无法覆盖本地连接、认证失败等场景，仅为事后追溯手段。
MySQL 8.0 自带的 audit_log 插件**不能直接识别或标记“SQL注入”行为**，它只记录连接、查询开始/结束、DDL/DML 事件等元数据，不解析 SQL 语句内容、不判断语法异常、不匹配攻击特征——这点必须先明确，否则会误以为开了审计就等于防住了注入。
audit_log 能捕获哪些与注入相关的线索
虽然不“检测”注入，但它能留下关键上下文，供后续人工或脚本排查可疑模式：
-
audit_log_policy = ALL会记录每次QUERY事件的sql_command（如Execute、Select）、status（成功/失败）、user、ip、timestamp和原始sql_text字段（仅限 JSON 格式） - 失败查询（
status: "ERROR"）若集中出现在同一 IP 或用户下，且sql_text含UNION SELECT、OR 1=1、sleep(等典型 payload 片段，就是强信号 - 高频短时连接 + 短命查询（如 1 秒内建连、发查、断开），常对应自动化扫描器行为
必须设成 JSON 格式，否则拿不到 sql_text
audit_log_format = NEWLINE 或 OLD 完全不包含 sql_text 字段，所有查询内容都不可见；只有 JSON 格式会在每条记录中带 "sql_text": "SELECT * FROM users WHERE id = '1' OR '1'='1'" 这样的字段。配置错误等于白开。
- 在
my.cnf的[mysqld]段落里写死：audit_log_format = JSON - 别依赖
SET GLOBAL动态修改——该变量是只读的，运行时改无效 - 确认插件已加载且状态为
ACTIVE：SELECT PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'audit_log';
日志解析要逐行处理，不能当完整 JSON 文件读
JSON 格式不是标准数组，而是**每行一个独立 JSON 对象**（line-delimited JSON）。直接 cat audit.log | jq '.' 会报错；正确做法是用循环逐行解析：
while IFS= read -r line; do
[ -n "$line" ] && echo "$line" | jq -r 'select(.sql_command == "Query" and .sql_text and (.sql_text | test("UNION|sleep\(|OR 1=1"))) | "(.timestamp) (.ip) (.user) (.sql_text)"'
done
- 上面脚本提取含
UNION、sleep(、OR 1=1的查询，并打印时间、IP、用户和语句 -
sql_text字段只在QUERY类型事件中存在，且受audit_log_policy控制：设成LOGINS就根本不会记录任何查询内容 - 注意：存储过程内部动态拼接的 SQL、
mysqldump导出命令、复制线程操作，audit_log默认不捕获——这些盲区得靠网络层（如代理、WAF）或应用层日志补位
真正漏掉的高危场景比你想象的多
即使配置全对，以下情况仍不会出现在 audit.log 里：
- Unix socket 登录（如
mysql -u root本地直连），audit_log默认不记录，ip字段为空，record类型也不是connect - 认证失败（密码错、用户不存在）只记在错误日志（
error.log），audit_log只记录成功建立连接后的事件 - 权限不足导致的查询拒绝（
ERROR 1142）虽会记status: "ERROR"，但sql_text可能被截断或为空，取决于 MySQL 版本和编译选项
所以单靠 audit_log 做注入监控，本质是“事后捞日志”，不是实时阻断；真要防御，得结合应用层输入校验、预编译语句、WAF 规则和数据库账号最小权限原则——审计日志只是最后一道追溯防线，而且有明显缺口。
