SQL高并发插入如何保证数据唯一性？

最可靠的做法是跳过预查直接INSERT并捕获1062错误，在应用层处理冲突；ON DUPLICATE KEY UPDATE和ON CONFLICT需依赖唯一索引，否则无效。

MySQL 直接 INSERT + 捕获 1062 错误最可靠

查再插（SELECT THEN INSERT）在高并发的情况反赌定会失败，这并非是逻辑编写得不够细致，而是数据库层根本无法通过两次语句来确保原子性。试想一下，两个请求几乎同时执行SELECT操作并返回空值，紧接着都执行INSERT操作，那么第二个操作必然会报Duplicate entry 'xxx' for key 'yyy'错误，且错误码固定为1062。

真正稳的做法是：跳过预查，直接发 INSERT，在应用层捕获 1062 或 SQLSTATE '23000'：

• Ja va 用 SQLException.getSQLState() 判断是否等于 "23000"，或 getErrorCode() == 1062
• Python pymysql 抛出 IntegrityError，err.args[0] 可取错误码
• Go 的 mysql.ErrNoReferencedRow 不适用，得用 errors.Is(err, mysql.ErrDupKey)（需驱动支持）

捕获后不 panic，而是走业务分支——比如返回“已存在”，或转为更新逻辑。这比加锁、查缓存、前端防重都更贴近数据库真实能力。

MySQL ON DUPLICATE KEY UPDATE 要求唯一索引必须存在

ON DUPLICATE KEY UPDATE 不是万能语法糖，它只在冲突字段上有 PRIMARY KEY 或 UNIQUE KEY 时才生效。没建索引就写这个语句，MySQL 会当普通 INSERT 执行，冲突时照样报 1062 错误，不会自动切到 UPDATE。

常见疏漏点：

• 联合唯一索引如 (user_id, event_type)，必须在 ON DUPLICATE KEY UPDATE 中写全列，或显式指定约束名：ON DUPLICATE KEY UPDATE ... 后面不能只写 ON CONFLICT (user_id)（那是 PostgreSQL 写法）
• VALUES(column) 引用的是本次 INSERT 子句里的值，不是当前行旧值；别误写成 count = count + 1，那需要先 SELECT 再计算，破坏了原子性
• 批量插入时，每行独立触发冲突判断，但整个语句仍是一次网络往返，性能远优于逐条处理

PostgreSQL 必须用 ON CONFLICT DO UPDATE，没有 MERGE

PostgreSQL 不支持标准 SQL 的 MERGE，也不接受 ON DUPLICATE KEY UPDATE。唯一合规的 UPSERT 是 ON CONFLICT 语法，且必须明确指定冲突目标——要么是索引名，要么是列名组合。

例如唯一索引叫 un_phone，就得写：

INSERT INTO users (phone, name) VALUES ('138xxxx', 'Alice') 
ON CONFLICT ON CONSTRAINT un_phone 
DO UPDATE SET name = EXCLUDED.name, updated_at = NOW();

注意：

• EXCLUDED 是伪表，代表本次想插入但被拒绝的那行数据，不是原记录
• 如果唯一约束是联合索引 (date, type)，不能只写 ON CONFLICT (date)，否则可能匹配错行；必须写 ON CONFLICT (date, type) 或索引名
• 加 WHERE 条件可做精细控制，比如 DO UPDATE SET ... WHERE users.status IS NULL，避免覆盖已有有效状态

高并发下死锁不是小概率事件，而是设计缺陷信号

当你看到日志里反复出现 Deadlock found when trying to get lock，尤其在插入不同业务数据时（比如不同 now_date），大概率是唯一索引设计或语句写法出了问题。

典型诱因：

• 联合唯一索引字段顺序不合理，导致间隙锁范围过大；比如 (cinema_id, show_id, now_date) 中 now_date 放最后，InnoDB 可能对前两列的间隙加锁，引发争用
• 用了 REPLACE INTO：本质是 DELETE + INSERT，会触发外键级联、自增 ID 跳变，还可能清空二级索引缓存
• 事务中混用 SELECT ... FOR UPDATE 和 INSERT，但 SELECT 没走索引，InnoDB 升级为表锁或大范围间隙锁

真正该盯住的，不是怎么绕开死锁，而是检查唯一索引是否精准覆盖业务冲突维度、ON DUPLICATE KEY UPDATE 或 ON CONFLICT 是否真被触发、以及批量大小是否超过单条 SQL 吞吐阈值——这些比调隔离级别更治本。