audit_log_format 设置成 STATEMENT 还是 JSONMySQL 审计日志的 audit_log_format 只支持两个值NEWLINE已弃用、JSON没有 STATEMENT 选项。官方文档里写的 “STATEMENT” 是旧版 MySQL Enterprise Audit 插件的遗留描述5.7.28 和 8.0.x 中实际只认 JSON —— 设成其他值会导致插件加载失败或日志静默丢弃。实操建议必须设为 JSON否则 audit_log 插件可能无法启用启动时会报错 Plugin audit_log init function returned error配置方式是在 my.cnf 的 [mysqld] 段下写 audit_log_formatJSON不能带引号、空格或注释改完后要重启 mysqld在线 SET 不生效该变量是只读的read_onlyaudit_log_policyALL 不等于“记录所有语句”很多人以为设了 audit_log_policyALL 就能抓到每个 SELECT 或 INSERT其实它只控制“审计事件类型”的粒度比如连接、断开、查询开始/结束、表访问等不控制 SQL 语句体是否写入日志。真正决定语句内容是否落盘的是 audit_log_include_accounts 和 audit_log_exclude_accounts 的匹配逻辑以及用户权限如是否拥有 AUDIT_ADMIN。常见错误现象日志里只有 connect / disconnect 事件没看到 query 类型 —— 很可能是账号被 audit_log_exclude_accounts 匹配到了root 用户有日志普通用户没有 —— 检查该用户是否被显式排除或是否缺少 AUDIT_ADMIN 权限部分版本要求audit_log_policyALL 下仍漏日志 —— 实际上 MySQL 默认只对具备 SUPER 或 AUDIT_ADMIN 的会话开启完整事件捕获普通用户默认只记 connect/disconnectaudit_log_file 路径写错会导致插件静默失效audit_log_file 不是普通日志路径它受 MySQL 启动用户权限和 secure_file_priv 限制。设成 /var/log/mysql/audit.log 看似合理但如果 mysqld 是以 mysql 用户运行而该目录属主是 root 且无写权限插件不会报错而是直接放弃写日志 —— 表现为“配置全对但文件始终为空”。 Wegic AI网页设计和开发工具