第三章 审计日志结构：字段与存储方式

审计日志说白了就是数据库的「黑匣子」。谁、什么时候、干了什么、结果如何，全记录在里边。我记得刚开始做审计模块时，总觉得多记几个字段无所谓，结果日志表一个月涨了 30GB……嗯，字段设计不对，后面全白费。这一章咱们就捋清楚：哪些字段是必须的，日志又该放哪儿。

3.1 核心字段清单

先列一个我常用的字段模板。你直接拿去用，基本覆盖了所有审计场景。

我自己一般在 event_time 和 db_user 上建联合索引。为什么？排查时最常用的两个过滤条件就是「谁在什么时间段干了什么」。

3.2 存储方式选型

日志存哪？这个选择直接决定了后续查询和维护的代价。我经历过三种主流方案，优缺点给你摆一下。

我个人倾向先用独立审计库。为什么呢？同库方案我之前吃过亏：有一次业务高峰，审计日志写入把 tempdb 撑爆了，整个库都挂掉。后来改成独立库，再没出过这个幺蛾子。

3.3 分区与归档策略

日志表永远在增长。不分区，等表超过 1 亿行，查询直接慢成幻灯片。我习惯按月分区，保留最近 12 个月。

CREATE TABLE audit_log (
  log_id      BIGINT NOT NULL,
  event_time  DATETIME(3) NOT NULL,
  -- 其余字段略
) ENGINE=InnoDB
PARTITION BY RANGE (TO_DAYS(event_time)) (
  PARTITION p202301 VALUES LESS THAN (TO_DAYS('2023-02-01')),
  PARTITION p202302 VALUES LESS THAN (TO_DAYS('2023-03-01')),
  -- 每月一个分区
  PARTITION p_future VALUES LESS THAN MAXVALUE
);

为什么要留一个 p_future？你想想看，如果上个月忘记建分区，新的日志会直接报错。留着最大分区兜底，再定期用 REORGANIZE PARTITION 拆出来。

上面这张图把字段和存储串起来了。你仔细看箭头方向——所有字段流最终汇入存储层。但是注意，这里没有「最佳方案」，只有「适合你的方案」。如果你每日日志量不到 10 万行，同库审计表完全够用；如果超过 500 万行，我建议直接上外部存储。

3.4 字段设计细节

再补充几个容易踩坑的点。

• 时间精度： 一定要用 DATETIME(3) 记到毫秒。我见过用 TIMESTAMP 的，结果同一秒内多个操作排不出顺序，排查时气到拍桌子。
• 用户标识： 千万别只记应用层用户名。有一次安全问题，DBA 要找真正的数据库登录名，结果日志里全是 app_user，彻底抓瞎。必须记 CURRENT_USER() 返回的原始账户。
• SQL 截断： VARCHAR(4000) 不够用，但用 TEXT 又太占用行空间。我习惯存前 2000 字符，超长部分用 MD5 存校验码，必要时通过应用日志补全。
• JSON 字段： MySQL 5.7+ 的 JSON 类型非常好用，可以直接在应用层传额外键值对。比如在 extra_info 里记 {"app_module":"订单","request_id":"abc123"}，排查效率翻倍。