INSERT IGNORE能跳过唯一键冲突，是因为它将ERROR 1062重复键错误降级为警告，仅对PRIMARY KEY或UNIQUE约束生效，不改动已有数据，也不触发自增ID递增或触发器。
INSERT IGNORE 为什么能跳过唯一键冲突
当多线程同时插入相同 UNIQUE 或 PRIMARY KEY 值时，MySQL 默认会抛出 1062 Duplicate entry 错误。用 INSERT IGNORE 可让语句静默失败——不报错、不回滚事务、不中断执行，只跳过冲突行。
但要注意：它会忽略所有重复错误，也包括你本想捕获的其他约束问题（比如外键失败），所以仅适用于「明确只担心唯一键冲突」的场景。
-
INSERT IGNORE INTO users (id, name) VALUES (123, 'Alice');—— 若id已存在，整条 INSERT 被丢弃，不影响后续语句 - 它不会改变
LAST_INSERT_ID()，也不触发AUTO_INCREMENT值递增（这点常被忽略） - 在事务中使用时，它仍属于 DML 操作，会加锁（如
INSERT ... ON DUPLICATE KEY UPDATE的锁范围更小）
ON DUPLICATE KEY UPDATE 怎么安全更新已存在行
比起跳过，有时你需要“存在则更新”，比如统计计数器或刷新时间戳。这时 ON DUPLICATE KEY UPDATE 是更可控的选择，它只对触发唯一键冲突的那行生效，且支持引用原值。
关键点在于：它只会更新由冲突索引（UNIQUE 或 PRIMARY KEY）定位到的单行，不会波及其他匹配条件的行。
INSERT INTO counters (name, value) VALUES ('login_count', 1) ON DUPLICATE KEY UPDATE value = value + 1;- 如果
name是UNIQUE索引，该语句要么插入新记录，要么对已有记录原子性地自增 - 注意：不能在
UPDATE子句里引用未在VALUES()中出现的新列值（比如ON DUPLICATE KEY UPDATE updated_at = NOW(), status = 'active'是允许的；但若status不在前面VALUES里，且没默认值，就可能出错）
REPLACE INTO 的隐式 DELETE-INSERT 风险
REPLACE INTO 看似简单，但它本质是「先尝试 DELETE 冲突行，再 INSERT 新行」。这会导致几个不易察觉的问题：
- 自增 ID 会被消耗（即使最终插入的是同一行），造成 ID 空洞
- 外键级联操作可能被意外触发（比如关联的
comments表设置了ON DELETE CASCADE） - 触发器会执行两次（
BEFORE DELETE+BEFORE INSERT），逻辑可能错乱 - 在高并发下，两个线程同时
REPLACE同一行，可能产生竞态：A 删除 → B 删除（发现无数据）→ B 插入 → A 插入 → 最终两条记录
除非你明确需要重置整行（包括清空未在 VALUES 中指定的列），否则避免用 REPLACE INTO 处理并发插入。
应用层怎么配合避免盲目重试
SQL 层解决冲突只是半步。如果业务逻辑要求「必须插入成功」，比如生成订单号，光靠 IGNORE 或 UPDATE 不够——你需要应用层生成唯一值（如 UUID、snowflake ID），或用 SELECT ... FOR UPDATE 预占资源。
- 不要写死循环重试
INSERT：网络延迟+锁等待可能导致雪崩 - 对低频关键操作（如注册用户名），可用
SELECT ... FOR UPDATE加行锁判断是否存在，再决定 INSERT；但注意锁粒度和超时设置 - 高频场景（如埋点日志）建议改用幂等设计：用客户端生成唯一
request_id，服务端查重后跳过，而非依赖数据库唯一索引硬扛
真正难的不是语法选哪个，而是判断「冲突是否可接受」「失败后要不要通知上游」「状态一致性由哪一层保证」——这些决定了 SQL 写法只是最后落地的一环。
