你的这个方案完全可行，甚至可以说是针对当前痛点的最优选择之一，原因如下：

• 你提到MongoDB内置审计过滤器会降低性能，而将审计日志剥离到独立的MySQL实例，完全避免了对业务MongoDB集群的性能干扰，不会占用MongoDB的计算、存储和复制资源。
• 审计日志存储量激增的问题，通过MySQL隔离后，不会影响MongoDB集群的节点复制效率——毕竟复制流里不再包含大量日志数据，能显著减轻集群的同步压力。
• 审计日志查看频率低的特点，刚好适配MySQL的结构化存储优势：虽然MySQL的写入性能不如MongoDB，但低频率的查询场景下，MySQL的索引优化和结构化查询能力反而能更高效地支撑按时间、操作人、集合类型等维度的检索需求。

结合你的场景，给你几个落地的关键点：

1. 设计合理的MySQL审计日志表结构 #

因为MongoDB是文档型数据库，审计日志需要兼容文档操作的特性，建议用MySQL的JSON类型存储操作内容，示例表结构如下：

CREATE TABLE audit_logs (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    operation_time DATETIME(3) NOT NULL COMMENT '操作时间（精确到毫秒）',
    operator VARCHAR(64) NOT NULL COMMENT '操作人ID/名称',
    mongo_collection VARCHAR(128) NOT NULL COMMENT '操作的MongoDB集合名',
    operation_type ENUM('INSERT', 'UPDATE', 'DELETE', 'FIND') NOT NULL COMMENT '操作类型',
    operation_details JSON NOT NULL COMMENT '操作详情：比如插入的文档、修改前后的字段快照',
    client_ip VARCHAR(45) COMMENT '客户端IP',
    status ENUM('SUCCESS', 'FAILED') NOT NULL COMMENT '操作状态',
    trace_id VARCHAR(64) COMMENT '链路追踪ID，关联业务操作'
);

给高频查询字段加索引：

CREATE INDEX idx_audit_time ON audit_logs(operation_time);
CREATE INDEX idx_audit_collection_operator ON audit_logs(mongo_collection, operator);

2. 采用异步写入机制，避免阻塞业务流程 #

不要在MongoDB业务操作的主流程里同步写入MySQL审计日志，否则会增加业务请求的响应时间。推荐用消息队列做异步解耦：

• 业务操作完成后（比如MongoDB的增删改操作成功返回），将审计事件（包含操作人、集合名、操作详情等）发送到消息队列（如Kafka、RabbitMQ）。
• 单独启动一个消费服务，从队列中拉取审计事件，批量写入MySQL。这样既不影响主业务的性能，也能保证审计日志的最终一致性。

3. 日志归档与存储优化 #

虽然审计日志查看频率低，但长期积累下来数据量还是不小，建议做以下优化：

• 给audit_logs表按operation_time做分区（比如按季度分区），历史分区可以设置为只读，避免误修改。
• 定期将超过一定期限（比如6个月或1年）的日志归档到低成本存储（如归档型MySQL实例、CSV文件存储），需要查询时再从归档中检索。

4. 保证审计日志的不可篡改 #

审计日志的核心要求是真实可信，所以要确保MySQL中的日志无法被随意修改：

• 给审计日志表设置严格的权限：只有审计服务有写入权限，其他角色仅能只读查询。
• 可以给每条日志添加哈希值字段，记录日志内容的哈希摘要，后续可以通过校验哈希值验证日志是否被篡改。

5. 关联业务操作的链路追踪 #

如果你的应用已经有链路追踪体系，可以给每条审计日志添加trace_id字段，和业务操作的追踪ID关联，方便后续排查问题时，快速定位对应的MongoDB操作和审计日志。

内容的提问来源于stack exchange，提问作者Ritesh kumar Agrahari