MySQL社区版默认不提供审计日志功能；企业版需手动安装audit_log插件并配置audit_log=FORCE_PLUS_PERMANENT等参数才能启用，且默认未开启。
MySQL 审计日志是否默认开启？
不开启。MySQL 社区版（即最常用版本）**默认完全不提供审计日志功能**，AUDIT_LOG 插件仅存在于 MySQL Enterprise Edition（企业版），社区版用户直接执行 INSTALL PLUGIN audit_log SONAME 'audit_log.so' 会报错 Plugin 'audit_log' is not loaded。
如果你用的是社区版，必须借助第三方方案，比如：
-
mysql-audit（McAfee 开源插件，需自行编译适配版本，支持 5.7/8.0） - 启用通用查询日志（
general_log）并配合日志轮转与访问控制——但性能开销大、无结构化事件类型 - 使用代理层（如 ProxySQL、MaxScale）记录客户端行为
如何验证 audit_log 插件是否已正确加载（企业版）
即使安装了企业版，audit_log 插件也**不会自动启用**，需手动加载并确认状态：
INSTALL PLUGIN audit_log SONAME 'audit_log.so'; SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'audit_log';
若返回 PLUGIN_STATUS 为 ACTIVE，说明加载成功；否则检查错误日志中是否有类似 Can't open shared library 'audit_log.so' 的提示——常见原因是插件路径不对或 SELinux 阻止了动态库加载。
关键配置项（需写入 my.cnf 并重启）：
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
-
audit_log=FORCE_PLUS_PERMANENT：强制加载且不可卸载（推荐） -
audit_log_format=NEW：输出 JSON 格式（兼容性好，便于解析） -
audit_log_policy=ALL：记录所有连接、查询、管理命令（LOGINS或QUERIES可缩小范围） -
audit_log_file=/var/log/mysql/audit.log：确保 MySQL 进程对该路径有写权限，且磁盘空间充足
audit_log 输出内容里哪些字段最关键？
JSON 格式的每条审计记录包含大量字段，但实际安全分析中应优先关注：
-
"name":"connect"或"name":"query"：区分是登录事件还是 SQL 执行事件 -
"status":0表示成功，非零值（如1045）代表认证失败，高频出现可能意味着暴力破解 -
"user":"app@10.10.20.5"：含来源 IP，比仅看用户名更能定位异常访问源 -
"query":"DROP TABLE users"：敏感操作明文记录（注意：长查询会被截断，受audit_log_read_buffer_size影响） -
"timestamp":"2024-04-12T09:23:41"：时区为 UTC，做关联分析时需统一时间基准
不要依赖 "os_login" 或 "priv_user" 字段做权限判断——它们在普通连接下常为空，真实权限由 user + host 组合决定。
审计日志的性能与落盘风险怎么平衡？
开启 audit_log 后，每个语句都会触发一次磁盘 I/O 写入，QPS 超过 500 时可能明显拖慢响应。更隐蔽的风险是：audit_log 默认同步写入（audit_log_flush=ON），一旦磁盘满或挂载点不可写，MySQL 可能直接拒绝新连接（ERROR 2013 (HY000)）。
缓解方式：
- 设
audit_log_flush=OFF改为异步刷盘（但崩溃时最多丢失 1 秒日志） - 用
audit_log_strategy=ASYNCHRONOUS（8.0.26+），进一步降低阻塞概率 - 禁止将审计日志和数据文件放在同一块物理盘上
- 用
logrotate配合audit_log_rotate_on_size自动切分，避免单文件过大
真正棘手的是：当攻击者拿到 DBA 权限后，可直接执行 SET GLOBAL audit_log_policy = NONE; 关停审计——所以审计日志本身必须由独立账号只读采集，并实时外发到 SIEM 系统。
