MySQL 自带的 general_log 能不能当安全审计用？
不能直接当生产环境的安全审计工具用。它记录所有语句（包括
SELECT、
SET、密码明文等），开启后 I/O 压力大、日志体积爆炸，且不区分用户操作上下文，也缺乏事件类型分类和告警能力。
general_log = ON会显著拖慢高并发写入场景，尤其在 SSD 性能受限或日志落盘慢的机器上 日志中
mysql -u root -p123456这类命令可能泄露密码，不符合最小权限与敏感信息脱敏原则 无法过滤出高危操作（如
DROP TABLE、
GRANT、
ALTER USER），需人工 grep，漏报率高
MySQL 8.0+ 的 audit_log 插件怎么启用和配置？
这是官方推荐的轻量级审计方案，只记录连接、查询、管理类事件，支持 JSON 格式输出和白名单过滤，但必须用企业版或 MySQL Community Server 8.0.30+（社区版从该版本起内置）。
INSTALL PLUGIN audit_log SONAME 'audit_log.so'; SET GLOBAL audit_log_policy = 'ALL'; SET GLOBAL audit_log_format = 'JSON'; SET GLOBAL audit_log_file = '/var/log/mysql/audit.log';启动前确认
audit_log.so文件存在：
ls /usr/lib/mysql/plugin/audit_log.so
audit_log_policy = 'LOGINS,QUERIES'比
ALL更可控，避免记录无意义的空连接 日志文件路径需确保 MySQL 用户有写权限，否则插件加载成功但实际无输出 JSON 格式里
"status": 0表示执行成功，非零值（如 1045）才是认证失败类风险事件
如何用 pt-audit 分析 audit_log 输出的 JSON 日志？
pt-audit（Percona Toolkit 中的工具）是目前最实用的日志解析器，能把原始 JSON 转成可读表格、按用户/命令/错误码聚合统计，还能导出 CSV 供 SIEM 系统接入。
pt-audit --format json /var/log/mysql/audit.log \ --filter 'event["status"] != 0' \ --report \ --group-by user,event[command]必须加
--format json，否则默认按旧版 XML 解析会报错
--filter支持 Python 表达式，比如
'event["command"] in ["DROP", "GRANT", "ALTER USER"]'可精准捕获权限变更行为 注意
pt-audit不实时监听，适合离线分析；如需实时告警，得配合
tail -f+
awk或 Filebeat 若 audit_log 开启了 rotation（
audit_log_rotate_on_size），需轮询多个文件，
pt-audit *.log会自动合并处理
审计日志权限本身该怎么控制？
审计日志文件和 MySQL 内部 audit_log 相关变量，必须严格限制访问权限，否则审计就失去意义。
OS 层面：chown mysql:adm /var/log/mysql/audit.log && chmod 640 /var/log/mysql/audit.log，禁止普通用户读取 MySQL 层面：禁用非管理员查看 audit_log 变量，执行
REVOKE SELECT ON *.* FROM 'auditor'@'%';后再
GRANT SELECT ON performance_schema.* TO 'auditor'@'%';，避免其看到
audit_log_policy等敏感配置 不要把 audit_log 写到
/tmp或 web 可访问路径下，曾经有案例因配置错误导致
audit.log被 HTTP 直接下载
audit_log 插件不记录 SQL 参数（如
WHERE id = ?中的值），所以对防 SQL 注入类行为无能为力；真要覆盖这类场景，得上代理层（如 ProxySQL）或专用 WAF，不是靠日志审计能解决的。
