MyBatis批量操作实战（ON DUPLICATE KEY核心技巧大公开）

第一章：MyBatis批量插入与ON DUPLICATE KEY概述

在高并发数据写入场景中，MyBatis作为持久层框架广泛应用于Java项目。当面对大量数据需要插入且存在主键或唯一索引冲突风险时，使用标准的`INSERT`语句可能导致异常或性能下降。此时，结合MySQL的`ON DUPLICATE KEY UPDATE`语法可实现“若存在则更新，否则插入”的逻辑，有效提升数据处理效率。

MyBatis批量插入基本用法

MyBatis通过` `标签实现批量操作。以下示例展示如何在Mapper XML中编写批量插入语句：

<insert id="batchInsertOnDuplicate">
  INSERT INTO user_info (id, name, email) VALUES
  <foreach collection="list" item="item" separator=",">
    (#{item.id}, #{item.name}, #{item.email})
  </foreach>
  ON DUPLICATE KEY UPDATE
    name = VALUES(name),
    email = VALUES(email)
</insert>

上述SQL利用`VALUES()`函数获取尝试插入的值，在发生主键或唯一键冲突时执行更新操作，避免了先查询后插入的额外开销。

ON DUPLICATE KEY UPDATE 的适用场景

该机制适用于以下情况：

• 统计数据实时累加，如用户访问次数
• 配置信息多线程写入，需保证最终一致性
• 消息去重表中防止重复记录

需要注意的是，该语法仅适用于MySQL数据库，并要求表中存在主键或唯一索引约束。

性能对比参考

方式	吞吐量（条/秒）	是否支持冲突处理
单条INSERT	~500	否
MyBatis批量INSERT	~8000	否
批量INSERT ON DUPLICATE	~6500	是

第二章：ON DUPLICATE KEY原理与SQL基础

2.1 ON DUPLICATE KEY UPDATE语义解析

在MySQL中， ON DUPLICATE KEY UPDATE用于处理插入数据时主键或唯一索引冲突的场景。该语句在检测到重复键时，自动转为更新操作，避免报错。

基本语法结构

INSERT INTO users (id, name, score) 
VALUES (1, 'Alice', 100) 
ON DUPLICATE KEY UPDATE score = score + 100;

上述语句尝试插入一条记录，若 id已存在，则将原有 score值增加100。

执行逻辑分析

• 首先尝试执行INSERT操作；
• 若发现主键或唯一约束冲突，则触发UPDATE分支；
• 可使用VALUES()函数引用原始插入值，如VALUES(score)表示插入时指定的score值。

该机制广泛应用于计数器更新、数据去重合并等场景，提升写入效率。

2.2 INSERT ... ON DUPLICATE KEY语法详解

MySQL 提供了 `INSERT ... ON DUPLICATE KEY UPDATE` 语句，用于在插入数据时处理唯一键或主键冲突的情况。当插入的记录与现有记录发生键冲突时，系统将执行更新操作而非报错。

基本语法结构

INSERT INTO table_name (column1, column2) 
VALUES (value1, value2) 
ON DUPLICATE KEY UPDATE 
column1 = VALUES(column1), 
column2 = VALUES(column2);

其中， VALUES(column) 表示本次插入尝试的值，可用于更新字段。

典型应用场景

• 计数器更新：避免先查后插导致的竞争条件
• 数据同步：确保远程源与本地表状态一致
• 幂等写入：重复请求下保证结果一致性

该机制基于唯一索引判断冲突，执行原子性操作，显著提升并发写入效率。

2.3 主键与唯一索引的触发机制分析

在数据库写入与同步过程中，主键（Primary Key）和唯一索引（Unique Index）承担着数据一致性的关键校验职责。当插入或更新操作发生时，数据库引擎首先检查主键约束，确保记录的唯一性。

约束触发顺序

通常，主键约束优先于唯一索引被验证。若主键冲突，操作立即终止，避免不必要的唯一索引检查，提升性能。

典型SQL示例

INSERT INTO users (id, email) VALUES (1, 'test@example.com')
ON DUPLICATE KEY UPDATE email = VALUES(email);

该语句在主键或唯一索引冲突时触发更新。其中 ON DUPLICATE KEY 监听所有唯一性约束冲突，包括主键和唯一索引。

冲突处理机制对比

约束类型	触发条件	性能影响
主键	主键值重复	高优先级，快速中断
唯一索引	索引列值重复	次级检查，开销略高

2.4 批量插入中冲突检测的底层流程

在批量插入操作中，数据库引擎首先对所有待插入记录进行唯一性预检。该过程通常基于索引扫描，识别与现有数据存在主键或唯一约束冲突的条目。

冲突检测阶段划分

• 预处理阶段：解析批量数据并构建临时哈希表
• 索引比对阶段：逐条比对目标表的唯一索引项
• 冲突标记阶段：标记冲突记录并决定后续策略（跳过、更新或报错）

INSERT INTO users (id, name) 
VALUES (1, 'Alice'), (2, 'Bob') 
ON CONFLICT (id) DO NOTHING;

上述语句在执行时，数据库会在唯一索引上检测 id=1 或 id=2 是否已存在。若存在，则跳过对应行插入。其底层依赖于唯一约束的 B+ 树索引快速查找能力，确保每条记录的冲突判断在 O(log n) 时间内完成。

2.5 与REPLACE INTO和INSERT IGNORE的对比

在MySQL中处理重复数据时，`INSERT ... ON DUPLICATE KEY UPDATE`、`REPLACE INTO` 和 `INSERT IGNORE` 提供了不同的策略。

执行机制差异

• INSERT IGNORE：忽略违反唯一约束的错误，跳过插入或更新操作；
• REPLACE INTO：删除旧记录并插入新记录，可能引发自增ID变更；
• ON DUPLICATE KEY UPDATE：仅在冲突时执行指定字段的更新，保留原有记录其他字段。

性能与副作用对比

语句	触发DELETE	自增ID变化	适用场景
REPLACE INTO	是	可能递增	全行替换
INSERT IGNORE	否	无	去重导入
ON DUPLICATE KEY UPDATE	否	无	精准更新

INSERT INTO users (id, name, views) 
VALUES (1, 'Alice', 10) 
ON DUPLICATE KEY UPDATE views = views + 1;

该语句在主键冲突时仅增加浏览量，避免不必要的删除与重建，更适合高频更新场景。

第三章：MyBatis批量操作核心配置

3.1 SqlSession批量执行器的使用方式

在MyBatis中，`SqlSession`提供了多种执行器类型，其中`BATCH`执行器适用于大量数据的批量操作，能显著提升性能。

启用批量执行器

创建`SqlSession`时指定执行器类型为`ExecutorType.BATCH`：

SqlSession session = sqlSessionFactory.openSession(ExecutorType.BATCH);

该模式下，MyBatis会缓存SQL语句并按需发送批量请求至数据库。

批量插入示例

• 通过循环调用insert方法积累操作
• 定期调用session.flushStatements()触发实际执行
• 最后必须调用commit()提交事务

for (User user : users) {
    session.insert("insertUser", user);
    if (i % 500 == 0) {
        session.flushStatements(); // 每500条刷新一次
    }
}
session.commit();

此策略减少与数据库的交互次数，提升吞吐量。

3.2 Mapper XML中动态SQL的构建技巧

在MyBatis的Mapper XML中，动态SQL是处理复杂查询条件的核心能力。通过灵活使用` `、` `、` `、` `等标签，可实现条件化SQL拼接。

条件判断与组合查询

<select id="findUsers" resultType="User">
  SELECT * FROM users
  <where>
    <if test="name != null">
      AND name LIKE CONCAT('%', #{name}, '%')
    </if>
    <if test="age != null and age > 0">
      AND age = #{age}
    </if>
  </where>
</select>

上述代码利用` `自动处理AND前缀问题，仅当条件成立时才拼接对应子句，避免语法错误。

多分支选择结构

使用` `模拟switch-case逻辑，适用于互斥条件：

• <choose>：包裹多个条件分支
• <when>：满足特定条件时生效
• <otherwise>：默认执行路径

该结构提升SQL可读性，避免冗余匹配。

3.3 参数封装与List传递的最佳实践

在处理复杂业务逻辑时，合理封装参数并安全传递List类型数据至关重要。良好的封装能提升代码可读性与维护性。

使用结构体封装请求参数

通过结构体聚合相关字段，避免散乱的参数传递：

type OrderQuery struct {
    Page   int      `json:"page"`
    Size   int      `json:"size"`
    IDs    []int64  `json:"ids"`
    Status []string `json:"status"`
}

该结构体将分页信息、ID列表和状态批量封装，便于API统一接收。

切片传递的注意事项

Go中切片是引用类型，直接传递可能引发数据竞争。建议：

• 避免在goroutine中直接修改共享切片
• 必要时使用 copy() 创建副本
• 对敏感数据进行深拷贝处理

第四章：实战场景与性能优化策略

4.1 单条SQL实现多记录upsert的编码示例

在现代数据处理场景中，高效地同步批量数据成为关键需求。使用单条SQL语句实现多记录upsert（插入或更新）能显著提升性能并保证原子性。

PostgreSQL中的Upsert实现

PostgreSQL通过`ON CONFLICT`语法支持upsert操作，适用于批量处理场景：

INSERT INTO users (id, name, email)
VALUES 
  (1, 'Alice', 'alice@example.com'),
  (2, 'Bob', 'bob@example.com'),
  (3, 'Charlie', 'charlie@example.com')
ON CONFLICT (id) 
DO UPDATE SET 
  name = EXCLUDED.name,
  email = EXCLUDED.email;

上述语句尝试插入三条记录，若主键`id`冲突，则用`EXCLUDED`引用新值进行更新。`EXCLUDED`是一个虚拟表，代表被阻止插入的行，使得字段映射清晰可控。

适用场景与优势

• 适用于ETL过程中的维度表更新
• 避免应用层多次往返数据库
• 保障批量操作的原子性和一致性

4.2 大数据量下的分批处理与事务控制

在处理大规模数据时，直接全量操作易导致内存溢出与事务超时。采用分批处理可有效缓解数据库压力，同时结合细粒度事务控制保障数据一致性。

分批读取与提交策略

通过设定固定批次大小，逐批读取并处理数据，每批完成后提交事务：

// 每批处理1000条记录
int batchSize = 1000;
for (int i = 0; i < totalRecords; i += batchSize) {
    List<Data> batch = dataMapper.selectBatch(i, batchSize);
    processBatch(batch);
    transactionManager.commit();
}

上述代码中， batchSize 控制每次加载的数据量，避免内存峰值； commit() 确保每批操作原子性，降低长事务风险。

异常回滚与断点续传

• 每批操作独立事务，失败时仅回滚当前批次
• 记录处理偏移量，支持故障后从断点恢复
• 结合日志追踪，提升可维护性

4.3 数据库连接池配置对批量性能的影响

合理配置数据库连接池是提升批量操作性能的关键因素。连接数过少会导致资源利用率低下，过多则可能引发数据库连接风暴。

连接池核心参数

• maxOpen：最大打开连接数，控制并发访问能力
• maxIdle：最大空闲连接数，减少频繁创建开销
• maxLifetime：连接生命周期，避免长时间占用

典型配置示例

db.SetMaxOpenConns(50)
db.SetMaxIdleConns(10)
db.SetConnMaxLifetime(30 * time.Minute)

上述代码设置最大50个并发连接，保留10个空闲连接，每个连接最长存活30分钟。在批量插入场景中，将 maxOpen 从10提升至50，吞吐量可提升近3倍。

性能对比

maxOpen	TPS（插入）	平均延迟(ms)
10	1200	83
50	3400	29

4.4 唯一键冲突的异常定位与日志追踪

在高并发数据写入场景中，唯一键冲突是常见异常之一。合理利用数据库返回的错误码与应用层日志记录机制，可快速定位问题源头。

典型错误信息识别

MySQL 中唯一键冲突通常返回错误码 1062，错误信息包含 "Duplicate entry" 字样：

ERROR 1062 (23000): Duplicate entry 'alice@domain.com' for key 'uk_email'

该信息表明在唯一索引 uk_email 上尝试插入重复值。

日志追踪策略

建议在捕获异常时记录完整上下文，包括：

• 请求ID（用于链路追踪）
• 操作类型（INSERT/UPDATE）
• 冲突字段名与值
• 调用堆栈与时间戳

异常处理代码示例

if err != nil {
    if mysqlErr, ok := err.(*mysql.MySQLError); ok && mysqlErr.Number == 1062 {
        log.Errorf("Unique constraint violation: %s, trace_id: %s", 
                   mysqlErr.Message, ctx.Value("trace_id"))
        return ErrDuplicateEntry
    }
}

上述代码通过判断 MySQL 错误类型精准捕获唯一键冲突，并输出结构化日志，便于后续分析与监控告警。

第五章：总结与生产环境建议

配置管理的最佳实践

在微服务架构中，集中式配置管理至关重要。推荐使用 Spring Cloud Config 或 HashiCorp Vault 实现动态配置加载，并结合 Git 作为后端存储，确保配置变更可追溯。

• 所有敏感信息（如数据库密码）应通过加密存储，避免明文暴露
• 配置更新后，通过消息总线（如 RabbitMQ）触发服务刷新，减少重启成本
• 为不同环境（dev/staging/prod）设置独立的配置分支，防止误操作

高可用部署策略

生产环境中应避免单点故障。Kubernetes 集群建议跨可用区部署至少三个控制节点，并使用反亲和性规则分散关键服务实例。

组件	副本数	健康检查间隔
API Gateway	4	10s
User Service	6	5s
Database	主从3节点	3s（自定义SQL探测）

性能监控与告警集成

使用 Prometheus + Grafana 构建监控体系，关键指标需包含请求延迟 P99、错误率和 JVM 堆内存使用率。

# prometheus.yml 片段
scrape_configs:
  - job_name: 'spring-boot-metrics'
    metrics_path: '/actuator/prometheus'
    static_configs:
      - targets: ['user-service:8080']
    relabel_configs:
      - source_labels: [__address__]
        target_label: instance

[API-Gateway] → [Service Mesh (Istio)] → [User-Service] ↓ [Prometheus ← Exporter]