on duplicate key update必须依赖主键或唯一索引才能触发,否则退化为普通插入;需确保表中明确定义unique key或primary key,且values()严格绑定对应行字段值。

MySQL批量Upsert必须依赖唯一约束才能触发ON DUPLICATE KEY
没有主键或唯一索引的表,INSERT ... ON DUPLICATE KEY UPDATE 会直接忽略冲突逻辑,变成普通插入——哪怕你写了ON DUPLICATE KEY UPDATE,也不会报错,但更新分支永远不执行。这是最常被忽略的前提。
常见错误是只加了普通索引(非UNIQUE)或误以为PRIMARY KEY自动覆盖所有字段。实际只要检查SHOW CREATE TABLE table_name输出里是否有UNIQUE KEY或PRIMARY KEY定义在你要匹配的列上即可。
- 单字段唯一:比如
username设为UNIQUE,那用username值冲突才会触发UPDATE - 组合唯一:如
(user_id, action_type)需提前建UNIQUE KEY idx_user_action (user_id, action_type) - NULL值注意:唯一索引允许多行
NULL,所以ON DUPLICATE KEY对NULL不生效,别拿它当“空值去重”用
VALUES子句必须合并成一条INSERT,不能拆成多条
MySQL的ON DUPLICATE KEY UPDATE只对**单条INSERT语句**生效。如果你把100条数据写成100个独立INSERT,就退化成100次单独判断+可能100次锁等待,性能断崖式下跌。
正确做法是用一个INSERT带多个VALUES元组,例如:
INSERT INTO users (id, name, email) VALUES (1, 'Alice', 'a@example.com'), (2, 'Bob', 'b@example.com'), (3, 'Charlie', 'c@example.com') ON DUPLICATE KEY UPDATE name = VALUES(name), email = VALUES(email);
这里VALUES(name)不是函数调用,而是MySQL内部语法糖,表示“本次VALUES列表中对应位置的name值”。它和VALUES子句严格位置绑定,不能跨行引用。
- 字段顺序必须完全一致,否则
VALUES(col)会取错值 - 每批建议≤500行:太长的SQL可能触发
max_allowed_packet或解析超时 - 避免在
VALUES里混用NULL和DEFAULT,显式写出更可控
MyBatis动态拼接时,VALUES括号不能漏、不能多嵌套
MyBatis的<foreach></foreach>容易在生成SQL时多加一层括号,导致语法错误。典型错误写法:VALUES (<foreach>(...)</foreach>),结果变成VALUES ((...), (...))——外层多了一对括号,MySQL直接报错ERROR 1064。
正确模板是让<foreach></foreach>直接生成逗号分隔的元组,外面不额外包括号:
<insert id="batchUpsert" parametertype="list">
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>
-
separator=","必须存在,否则生成的SQL缺逗号 - 不要在
<foreach></foreach>外再写VALUES或(,MyBatis会原样输出 - 如果字段含
NULL,确保Java对象字段为null而非空字符串,否则#{item.xxx}会生成''而非NULL
并发写入时,ON DUPLICATE KEY本身是原子的,但要注意事务边界
INSERT ... ON DUPLICATE KEY UPDATE整条语句在MySQL内是原子执行的,不会出现“查到不存在→准备插入→被别人插进去了→自己再插失败”的竞态。这点比先SELECT再INSERT/UPDATE可靠得多。
但批量操作仍需包裹在事务中,原因有两个:
- 如果某一批次里部分行因违反其他约束(如
CHECK、FOREIGN KEY)失败,整个语句会回滚,避免脏数据 - 高并发下,多个线程同时执行同一批
id的Upsert,虽然每条语句原子,但不同语句之间仍可能互相阻塞,需靠事务隔离级别控制可见性 - MyBatis中务必配
@Transactional或手动SqlSession管理,别依赖默认自动提交
真正容易被绕过的点是:你以为ON DUPLICATE KEY能兜住所有冲突,但它只响应唯一约束冲突;如果业务上还有逻辑校验(比如“余额不能为负”),得在应用层或触发器里补全,它不负责。











