MySQL DML语句审计指标采集及非触发器实现方案咨询

可选解决方案汇总 #

以下方案均不依赖表触发器，可覆盖你要求的所有审计指标：

方案1：二进制日志（Binlog）行模式解析 #

这是成本最低的原生实现方案，完全基于MariaDB内置功能：

• 核心配置：开启binlog并设置格式为ROW，同时开启binlog_rows_query_log_events参数记录原始DML语句
  参考配置（写入my.cnf后重启生效）：

  log_bin = /var/log/mysql/mariadb-bin
  binlog_format = ROW
  binlog_rows_query_log_events = ON
  expire_logs_days = 7 # 按需调整日志保留时长
  

• 可覆盖的所有审计指标：
  • 执行用户：Binlog事件头内置线程关联的用户信息
  • 执行时间：每个事件自带精准时间戳
  • 查询具体内容：binlog_rows_query_log_events开启后直接记录原始DML语句，无需反向还原
  • 受影响表：行模式Binlog的每个变更事件明确关联对应库表
  • 影响行数：每个行事件直接统计实际变更的行数，完全满足硬性要求
• 优势：不需要额外部署第三方组件，Binlog可通过mariadb-binlog工具或binlog2sql等开源工具解析为结构化格式，直接导出供外部系统处理，对数据库性能损耗远低于触发器。

方案2：Percona Server Audit Log插件 #

你测试的是MariaDB自带的审计插件，Percona分支提供的审计插件能力更丰富：

• 可配置规则过滤掉SELECT语句，仅记录DML操作，支持自定义输出字段，可直接包含执行用户、执行时间、SQL原文、影响行数等核心指标，SQL涉及的表可通过简单的语法解析从SQL语句中提取。
• 支持JSON格式直接输出审计日志，无需额外格式转换即可供外部系统解析。
• 注意：该插件可兼容部分版本的MariaDB，可先测试适配性，若适配失败可考虑将数据库切换为Percona Server（和MariaDB高度兼容，业务几乎无需改造）。

方案3：数据库代理层审计 #

在应用和数据库之间部署代理中间件，在流量层完成审计：

• 可选中间件：MariaDB官方的MaxScale、开源的ProxySQL均可
• 审计逻辑：所有SQL请求流经代理时即可采集执行用户、请求时间、SQL原文，SQL执行完成后代理可获取数据库返回的影响行数，同时代理侧可内置SQL解析能力提取涉及的表，直接拼接为结构化审计日志输出。
• 优势：完全和数据库侧解耦，不需要调整数据库配置，对数据库性能无额外损耗，可同时对接多个数据库实例统一审计，支持自定义日志输出格式直接对接外部日志系统。

方案4：存储过程封装审计（适配特定场景） #

如果你的业务所有DML操作都已封装为存储过程调用，可直接在存储过程中嵌入审计逻辑：

• 在存储过程执行DML语句后，直接获取ROW_COUNT()值作为影响行数，结合当前登录用户CURRENT_USER()、当前时间NOW()、执行的操作逻辑、涉及的表，统一写入独立的审计表中，指标100%可控。

选型建议 #

• 无额外部署预算的场景优先选方案1，成本最低完全满足要求
• 有多实例统一审计需求的场景优先选方案3
• 可接受数据库分支切换的场景优先选方案2，开箱即用

内容的提问来源于stack exchange，提问作者AJY