SQL日志审计表设计核心是分清职责、轻写入、快查询：主表存最小元数据，SQL和异常详情分表存储；通过批量异步、物理隔离、分区索引等优化性能；采样脱敏与分级存储平衡成本与安全。
SQL日志审计表的核心矛盾是：既要完整记录操作行为（字段多、写入频次高），又要保障业务库性能不被拖垮。关键不在“建得多”，而在“分得清、写得轻、查得快”。
审计表结构设计：只存关键元数据，业务上下文外置
避免把完整SQL语句、参数值、执行计划等全塞进一张表——这会导致单行过大、索引膨胀、写入变慢。应按职责拆分：
- 主审计表（audit_log）：仅存不可变的最小集合——操作时间（datetime）、操作人（user_id）、客户端IP（client_ip）、数据库名（db_name）、表名（table_name）、操作类型（INSERT/UPDATE/DELETE/SELECT）、影响行数（affected_rows）、耗时（duration_ms）、唯一请求ID（request_id）；主键用自增ID或时间+序列组合，不推荐UUID。
- SQL内容表（audit_sql_text）：按需关联，只存request_id + 截断后的SQL前512字符 + 参数占位符化后的模板（如UPDATE user SET status=? WHERE id=?）；启用压缩（MySQL 5.7+支持ROW_FORMAT=COMPRESSED）。
- 异常详情表（audit_error_detail）：仅当error_code非0时才写入，含错误码、错误消息、堆栈摘要；冷热分离，可考虑TTL自动归档。
高频写入优化：绕开主库、批量缓冲、异步落盘
审计日志本质是“事后追溯凭证”，允许毫秒级延迟，绝不和交易逻辑强耦合：
- 应用层用内存队列（如Disruptor、LMAX）或本地环形缓冲区暂存日志，每100条或每100ms批量刷到中间件；避免每条SQL都触发一次INSERT。
- 接入轻量级消息队列（Kafka/RocketMQ），审计SDK将日志发到topic，由独立消费者服务写入审计库；消费者按分区批量INSERT，关闭autocommit，显式事务控制。
- 审计库单独部署，与业务库物理隔离；表引擎选InnoDB，但关闭doublewrite（audit库可接受极低概率页损坏）、调大innodb_log_file_size（减少checkpoint频率）、设置innodb_flush_log_at_trx_commit=2（牺牲1秒内崩溃丢失，换写入吞吐翻倍）。
查询加速策略：按时间分区 + 冗余检索字段 + 覆盖索引
审计查询80%集中在最近7天、按用户/表/时间范围组合过滤，不必追求全字段模糊搜索：
- 按天或按周对audit_log表做RANGE分区（PARTITION BY RANGE (TO_DAYS(create_time))），删除旧分区比DELETE快百倍。
- 在主表中冗余常用查询字段：比如把user_name（而非仅user_id）同步过来，避免关联用户表；加字段sql_type ENUM('DML','DDL','DCL')，加速分类统计。
- 建联合索引覆盖高频查询路径：KEY idx_user_time_type (user_id, create_time, op_type)、KEY idx_table_time (table_name, create_time)；避免在TEXT字段上建全文索引——查SQL模板用LIKE 'UPDATE %'即可，加前导通配符不影响分区剪枝。
成本与安全平衡：采样+脱敏+分级存储
不是所有SQL都值得全量审计，也不是所有字段都该明文留存：
- 对SELECT类操作默认采样10%（通过RAND()
- 写入前对SQL文本做规则脱敏：正则替换身份证号、手机号、银行卡号为***，保留格式便于识别但不泄露真实值。
- 热数据（30天）放SSD+高配MySQL；温数据（30–180天）用列存引擎（ClickHouse）或转存OSS/S3；冷数据（>180天）压缩归档为Parquet，供离线审计平台拉取。
基本上就这些。不复杂，但容易忽略“审计不是监控”的本质——它不需要实时，但必须可靠；不需要全量，但必须可溯。建模先想清楚谁查、怎么查、查多久，再决定怎么写、写多少。
