audit_log_format 设置成 STATEMENT 还是 JSON？MySQL 审计日志的 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_format=JSON，不能带引号、空格或注释改完后要重启 mysqld；在线 SET 不生效，该变量是只读的（read_only）audit_log_policy=ALL 不等于"记录所有语句"很多人以为设了 audit_log_policy=ALL 就能抓到每个 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_policy=ALL 下仍漏日志 ------ 实际上 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网页设计和开发工具