一、为什么需要”只插入不更新”模式？

在分布式数据库场景下，数据更新操作往往带来复杂的同步问题。以电商订单系统为例，当用户下单后，订单数据需要被多个服务（支付、物流、库存）同时读取，若采用传统更新模式，可能出现：

1. 并发更新冲突导致数据不一致
2. 分布式事务性能瓶颈（如XA协议）
3. 历史数据追溯困难（无法回溯订单状态变更过程）

“只插入不更新”模式通过将数据变更转化为时间序列记录，有效解决了这些问题。每个数据变更都作为新记录插入，通过时间戳或版本号区分，形成不可变的日志式数据结构。

二、技术实现方案

1. 数据库表设计

CREATE TABLE order_events (
    event_id BIGINT PRIMARY KEY AUTO_INCREMENT,
    order_id VARCHAR(32) NOT NULL,
    event_type VARCHAR(32) NOT NULL, -- CREATE/PAY/SHIP等
    event_data JSON NOT NULL,        -- 存储具体业务数据
    create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    version INT DEFAULT 1,
    INDEX idx_order_time (order_id, create_time)
) ENGINE=InnoDB PARTITION BY HASH(order_id) PARTITIONS 8;

2. Java实现关键点

2.1 并发控制策略

@Transactional
public void insertOrderEvent(OrderEvent event) {
    // 使用数据库唯一约束防止重复
    try {
        orderEventRepository.save(event);
    } catch (DataIntegrityViolationException e) {
        // 处理重复插入逻辑
        log.warn("Duplicate event detected: {}", event.getOrderId());
    }
}

2.2 查询优化方案

// 查询订单最新状态
public OrderStatus getLatestStatus(String orderId) {
    String sql = "SELECT event_data->>'$.status' as status " +
                 "FROM order_events " +
                 "WHERE order_id = ? " +
                 "ORDER BY create_time DESC " +
                 "LIMIT 1";
    return jdbcTemplate.queryForObject(sql, String.class, orderId);
}

3. 分布式SQL优化

3.1 分区表设计

• 按order_id进行哈希分区，确保单个订单的所有事件落在同一分区
• 查询时通过WHERE order_id = ?实现分区裁剪

3.2 索引策略

• 复合索引(order_id, create_time)支持按订单和时间范围查询
• 函数索引（如MySQL 8.0+）支持JSON字段查询优化

三、典型业务场景应用

1. 审计日志系统

public void logUserAction(String userId, String action, JSONObject details) {
    AuditLog log = new AuditLog();
    log.setUserId(userId);
    log.setAction(action);
    log.setDetails(details);
    log.setIpAddress(RequestContext.getRemoteAddr());
    auditLogRepository.save(log);
}

优势：

• 天然支持时间线查询
• 无需担心日志修改问题
• 便于合规性审查

2. 物联网设备状态上报

-- 设备状态历史表
CREATE TABLE device_status (
    device_id VARCHAR(64) NOT NULL,
    status_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
    status_value VARCHAR(32) NOT NULL,
    battery_level INT,
    signal_strength INT,
    PRIMARY KEY (device_id, status_time)
) PARTITION BY RANGE (UNIX_TIMESTAMP(status_time)) (
    PARTITION p202301 VALUES LESS THAN (UNIX_TIMESTAMP('2023-02-01')),
    PARTITION p202302 VALUES LESS THAN (UNIX_TIMESTAMP('2023-03-01'))
);

查询最近状态：

public DeviceStatus getLatestStatus(String deviceId) {
    String sql = "SELECT * FROM device_status " +
                 "WHERE device_id = ? " +
                 "ORDER BY status_time DESC " +
                 "LIMIT 1";
    return jdbcTemplate.queryForObject(sql, new DeviceStatusMapper(), deviceId);
}

四、性能优化实践

1. 批量插入优化

@Transactional
public void batchInsertEvents(List<OrderEvent> events) {
    // 使用JdbcTemplate的batchUpdate
    jdbcTemplate.batchUpdate(
        "INSERT INTO order_events (order_id, event_type, event_data) VALUES (?, ?, ?)",
        new BatchPreparedStatementSetter() {
            @Override
            public void setValues(PreparedStatement ps, int i) {
                OrderEvent event = events.get(i);
                ps.setString(1, event.getOrderId());
                ps.setString(2, event.getEventType());
                ps.setString(3, event.getEventData().toString());
            }
            @Override
            public int getBatchSize() {
                return events.size();
            }
        }
    );
}

2. 查询缓存策略

@Cacheable(value = "orderStatusCache", key = "#orderId")
public OrderStatus getCachedStatus(String orderId) {
    return getLatestStatus(orderId); // 实际查询数据库
}

五、与更新模式的对比分析

指标	只插入不更新模式	传统更新模式
并发性能	高（无锁）	低（行锁）
数据一致性	强（时间序列）	依赖事务隔离级别
历史追溯	简单（完整日志）	复杂（需额外审计表）
存储空间	较高（时间序列）	较低
查询复杂度	中等（需聚合）	简单（直接查询）

六、实施建议

1. 分区策略选择：

   • 按业务ID哈希分区（适合订单类数据）
   • 按时间范围分区（适合时序数据）

2. 索引优化：

   • 为常用查询条件创建复合索引
   • 考虑使用覆盖索引减少回表

3. 数据清理策略：

   -- 定期归档历史数据
   CREATE TABLE order_events_archive LIKE order_events;
   INSERT INTO order_events_archive 
   SELECT * FROM order_events 
   WHERE create_time < DATE_SUB(NOW(), INTERVAL 1 YEAR);
   DELETE FROM order_events WHERE create_time < DATE_SUB(NOW(), INTERVAL 1 YEAR);

4. 监控指标：

   • 插入延迟（P99）
   • 分区大小分布
   • 查询响应时间

这种设计模式特别适用于需要完整审计轨迹、高并发写入、最终一致性的业务场景。通过合理设计表结构和查询策略，可以在保证数据一致性的同时，获得接近传统更新模式的查询性能。实际实施时，建议先在小规模业务中验证，再逐步推广到核心系统。