怎样解决MySQL中多个事务同时创建唯一记录的锁冲突-mysql教程-PHP中文网

on duplicate key update是唯一安全的原子方案，它将“判断是否存在”与“插入或更新”压缩为一条innodb层原子sql，需配合唯一索引（主键或unique key）才能生效，否则退化为全表扫描并仍报1062错误。

怎样解决mysql中多个事务同时创建唯一记录的锁冲突

ON DUPLICATE KEY UPDATE 是唯一安全的原子方案

想靠 SELECT 判断再 INSERT，必然在高并发下触发 ERROR 1062 (23000): Duplicate entry。这不是概率问题，是确定性竞态：两个事务查完都看到“不存在”，接着都执行插入，第二个必失败。唯一能绕过这个窗口的，是把“查”和“插/更”压进一条语句，在 InnoDB 层原子完成。

必须确保冲突字段已建 UNIQUE KEY 或主键，否则 ON DUPLICATE KEY UPDATE 语法无效，还会退化为全表扫描加锁。示例：

INSERT INTO user_profiles (user_id, nickname, updated_at) 
VALUES (123, 'alice', NOW()) 
ON DUPLICATE KEY UPDATE nickname = VALUES(nickname), updated_at = VALUES(updated_at);

VALUES(nickname) 引用的是本次 INSERT 子句里的值，不是原记录旧值
UPDATE 子句里别写子查询或函数（如 NOW() 要提前算好传入），MySQL 不支持且会强制走全表扫描
影响行数返回值有明确语义：0 表示冲突未更新，1 表示插入，2 表示更新——业务可据此做状态判断

为什么 REPLACE INTO 和 INSERT IGNORE 都不该用

REPLACE INTO 看似能“覆盖”，实际是 DELETE + INSERT 两步。它会触发外键级联、触发器、自增 ID 跳变，还可能清空二级索引缓存；更关键的是，并发下 DELETE 操作会持有间隙锁，极易引发死锁，尤其当唯一索引是非主键时。

INSERT IGNORE 表面安静，实则危险：它静默忽略所有警告级错误，不只是唯一冲突——比如字段超长被截断、NOT NULL 字段插了 NULL、时区转换失败等，这些本该报警的问题全被吞掉，排查成本陡增。

两者都破坏影响行数语义：INSERT IGNORE 对冲突行返回 0，REPLACE INTO 对已存在行返回 2（删 1 + 插 1）
它们都不解决根本问题：没有消除“查-判-写”的时间窗口，只是掩盖失败形式

唯一索引没建对，ON DUPLICATE KEY UPDATE 一样卡死

即使用了 ON DUPLICATE KEY UPDATE，如果冲突字段没走唯一索引，InnoDB 就无法快速定位目标行，查找阶段会扫描并尝试锁大量无关行；即使最终是插入，也会对“可能插入的位置”加间隙锁，导致其他事务在相同间隙插入时被阻塞。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

检查方式很简单：用 EXPLAIN 看执行计划，确认 type 是 const、eq_ref 或 ref，且 key 列显示命中了你建的唯一索引。常见坑点：

联合唯一索引列顺序错：UNIQUE KEY uk_user_type (user_id, type)，但 WHERE 只写了 type = ?，索引失效
字段类型不一致：比如 user_id 是 BIGINT，但传字符串 '123'，触发隐式转换丢索引
NULL 值不参与唯一判定：MySQL 允许多个 NULL，若业务允许空值，需额外校验