当前位置：首页 > 文章列表 > 数据库 > MySQL > MySQL Enterprise Audit 怎么按用户过滤：audit_log_filter_set_filter 与查询统计

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

来源：17golang原创 2026-08-21 11:26:26 0浏览收藏

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

要点速览

这套函数属于 MySQL Enterprise Audit，社区版不能按同样前提直接套用。
过滤器用 JSON 定义，可按事件类、子类和字段值决定记录或忽略。
过滤器定义和用户分配是两步，改完必须用查询确认账号当前绑定关系。
查询时间、发送接收字节数、返回行数和扫描行数属于可选查询统计字段，开启前要评估日志体积。

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

不要先写 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" } }
      ]
    }
  }'
);

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

MySQL Enterprise Audit 事件进入 JSON 过滤器后按连接和表访问分流的真实性场景

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

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

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" }
        }
      }
    ]
  }
}

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

MySQL Enterprise Audit 按用户分配过滤器并在事件中补充查询时间和扫描行数的真实性场景

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

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

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';

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