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并重启）：
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 系统。
