MySQL 5.7.20+ 和 8.0 中需手动安装 audit_log 插件并配置 audit_log_policy、audit_log_format、audit_log_file 三个参数，写入 my.cnf 的 [mysqld] 段后重启生效，动态 SET 无效，且不可与 MariaDB server_audit 等第三方审计插件共存。
MySQL 5.7+ 审计插件 audit_log 怎么启用
MySQL 自带的 audit_log 插件（非第三方 McAfee Audit Plugin）在 5.7.20+ 和 8.0 中默认编译进服务，但默认不加载。它不依赖外部库，开箱即用，但必须手动安装并配置日志路径权限。
实操建议：
- 先确认插件存在：
SHOW PLUGINS;查看是否有audit_log行，状态为DISABLED是正常的 - 动态安装：执行
INSTALL PLUGIN audit_log SONAME 'audit_log.so';（Linux）或'audit_log.dll'（Windows） - 安装失败常见原因是
audit_log.so文件不在plugin_dir下——查路径用SELECT @@plugin_dir;，再确认文件是否存在 - 安装后需设置参数才生效，仅安装不写配置等于没开
audit_log 相关配置项怎么设才不丢日志
插件启用后，audit_log_policy、audit_log_format、audit_log_file 这三个参数必须显式配置，否则可能写入失败或只记录极少量事件。
实操建议：
-
audit_log_policy推荐设为ALL或LOGINS，避免用VALIDATE（只记认证失败，容易误判为“没生效”） -
audit_log_format选JSON更易解析，但注意 MySQL 5.7.20+ 才支持；旧版本只能用NEWLINE（纯文本，每行一条） -
audit_log_file路径必须由 MySQL 进程用户（如mysql）有写权限，常见坑是设到/var/log/mysql/却忘了chown mysql:mysql /var/log/mysql - 所有参数需写进
my.cnf的[mysqld]段，并重启服务才持久——动态 SET 不生效
audit_log 写不进文件？常见错误和权限检查点
最常遇到的现象是：插件显示 ACTIVE，但指定路径下始终没生成日志文件，或日志空、只有一两行。
排查顺序：
- 查 MySQL 错误日志（
mysqld.err），搜索关键词audit_log或Can't open，往往直接报权限或路径不存在 - 确认
audit_log_strategy是ASYNCHRONOUS（默认）还是SEMISYNCHRONOUS：后者在写失败时会阻塞连接，导致业务卡住，新手容易误以为数据库挂了 - 用
ps aux | grep mysql看进程实际运行用户，再sudo -u mysql touch /path/to/audit.log测试写权限 - SELinux 或 AppArmor 启用时会拦截写操作，临时关闭测试：
setenforce 0（CentOS/RHEL）
audit_log 和第三方插件（如 MariaDB audit_plugin）能共存吗
不能。MySQL 官方 audit_log 和 MariaDB 的 server_audit 或旧版 McAfee libaudit_plugin.so 使用不同接口和内存模型，同时加载会导致 mysqld 启动失败或崩溃。
判断方法：
- 如果
INSTALL PLUGIN报错Function 'server_audit' already exists，说明已有其他审计插件在内存中 - 卸载前务必先
UNINSTALL PLUGIN server_audit;（或对应名字），再装audit_log - MySQL 8.0.19+ 已移除对 McAfee 插件的支持，强行加载会触发断言失败
- 生产环境切勿靠试错切换插件——审计是安全基线，换插件必须停服、清缓存、验证日志格式兼容性
真正麻烦的不是装不上，而是日志格式变更后下游解析服务没同步适配。比如从 NEWLINE 切到 JSON，旧的 logstash grok 规则就全失效。
