MySQL Enterprise Audit 怎么按用户过滤：audit_log_filter_set_filter 与查询统计

MySQL Enterprise Audit 开启后，最先变大的往往不是故障记录，而是健康检查、连接探活和后台账号产生的重复事件。继续保留全量日志当然方便，但排查一次真实变更时，审计文件很快就会变成噪声堆。MySQL 8.4 可以用 audit_log_filter_set_filter() 定义规则，再用 audit_log_filter_set_user() 按账号分配过滤器。

先确认插件和过滤接口是否存在

不要先写 JSON 再猜版本。MySQL Enterprise Audit 需要先安装 audit_log 插件及其伴随函数和表，实际安装脚本位于 MySQL 发行包的 share 目录。生产环境先确认授权版本、插件状态和审计日志落盘位置。

SHOW PLUGINS;

SELECT TABLE_SCHEMA, TABLE_NAME
FROM information_schema.TABLES
WHERE TABLE_NAME LIKE 'audit_log%';

如果函数不存在，先停止在业务账号上反复尝试。审计过滤不是普通 SQL 的兼容开关，安装、卸载和日志目录都应由数据库管理员按当前发行版文档处理。

用一个小规则收窄审计事件

过滤器的主体是 JSON。下面的示例只保留连接和表操作相关事件，结构故意保持小，先验证规则能被接受，再逐步加入用户条件和查询统计。

SELECT audit_log_filter_set_filter(
  'ops_review',
  '{
    "filter": {
      "class": [
        { "name": "connection", "event": { "name": "connect" } },
        { "name": "general", "event": { "name": "table_access" } }
      ]
    }
  }'
);

函数返回成功并不等于日志已经按预期变化。先查询过滤器定义，再用一个专用测试账号产生一条可识别事件；不要直接拿生产账号做大范围验证。

按账号分配过滤器，避免全局规则误伤

过滤器定义完成后，还要把它分配给目标用户。账号过滤比所有连接都套一套规则更容易控制范围，也方便为后台任务、报表账号和人工运维账号设置不同审计强度。

SELECT audit_log_filter_set_user(
  'report_user',
  'ops_review'
);

SELECT *
FROM mysql.audit_log_filter_user
WHERE USER = 'report_user';

部分环境会为没有显式分配过滤器的账号使用默认过滤器。上线前把显式分配和默认兜底分别列出来，尤其要检查应用连接池使用的账号是否被意外套上了过宽规则。

查询统计字段要单独评估日志成本

MySQL 8.4 支持把查询时间、发送和接收字节数、返回行数、扫描行数等统计信息加入 JSON 审计事件。它们对慢查询取证很有用，但会让每条相关事件携带更多字段。先只给排障账号开启，再观察文件大小和写入压力。

{
  "filter": {
    "class": [
      {
        "name": "general",
        "event": {
          "name": "status",
          "log": true,
          "service": { "name": "query_statistics" }
        }
      }
    ]
  }
}

这里不要把审计日志当成慢查询日志的替代品。审计更关心谁在什么上下文做了什么，而性能诊断工具更适合连续收集耗时和执行计划；两类数据应该互相补充。

修改、回滚和验收应该是一组动作

过滤器上线前保存旧定义和用户映射。修改时优先创建一个新名字的过滤器，在测试账号上验证，再切换绑定；出现日志量异常时可以迅速把账号切回原过滤器。

SELECT audit_log_filter_set_user('report_user', 'ops_review_v2');

SELECT audit_log_filter_set_user('report_user', 'ops_review');

SELECT * FROM mysql.audit_log_filter_user
WHERE FILTERNAME = 'ops_review_v2';

验收至少包含四件事：过滤器定义可读、用户绑定正确、测试事件出现在预期日志中、未命中的事件没有被误记录或误丢弃。最后再看审计文件增长速度和轮转策略，避免规则正确但磁盘先满。

常见问题

MySQL Community 能直接使用 audit_log_filter_set_filter 吗？

不能按 Enterprise Audit 的前提直接假设可用。先核对发行版和插件安装状态，再决定是否使用对应的审计能力。

定义过滤器后为什么账号日志没有变化？

常见原因是只定义了过滤器，没有调用用户分配函数，或者应用账号没有走预期的连接身份。先查用户映射表，再用专用测试连接验证。

过滤器能不能只记录某个数据库？

可以继续按事件字段值设计包含或排除条件，但应先用小范围测试确认 JSON 层级和事件字段名称，不要凭业务表名猜审计事件结构。

开启 query statistics 后最该看什么？

先看查询时间、扫描行数和日志增长量。它适合补充审计证据，不应替代慢查询、执行计划和容量监控。

结语：过滤规则要能解释，也要能撤回

审计过滤的价值不在于把日志变少，而在于让每条留下来的记录都能回答哪个账号、哪类事件、为什么保留。把版本前提、JSON 定义、用户映射、测试事件和回滚动作一起纳入变更记录，后续排障才不会只剩一份难以阅读的日志文件。