最可靠的做法是跳过预查直接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'：
- Java 用
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 吞吐阈值——这些比调隔离级别更治本。
