insert ignore仅对主键或唯一索引冲突静默跳过，其他错误仍报错；on duplicate key update适合“存在则更新”，语义明确；replace into会删除重建，有id变化、外键级联等风险。
INSERT IGNORE 会静默跳过重复记录，但只对主键或唯一索引冲突生效
它不是“忽略所有错误”，而是专门针对 PRIMARY KEY 或 UNIQUE 约束冲突时跳过当前行，不报错、不中断后续插入。其他错误（比如字段类型不匹配、NOT NULL 违反）照常报错。
常见错误现象：INSERT IGNORE 执行后没报错，但数据没插进去，还以为成功了——其实是因为某列触发了唯一约束冲突，被静默跳过了。
- 必须确保表里定义了
PRIMARY KEY或UNIQUE索引，否则INSERT IGNORE和普通INSERT行为完全一样 - 如果用的是联合唯一索引，只有所有列值组合完全相同时才会被忽略
- 注意：MySQL 8.0+ 中，
INSERT IGNORE在遇到警告（如截断字符串）时也会静默忽略，但这类行为不属于设计初衷，容易误判
INSERT ... ON DUPLICATE KEY UPDATE 更适合“存在则更新”场景
当你不想丢弃重复数据，而是想用新值覆盖旧字段时，ON DUPLICATE KEY UPDATE 是更明确的选择。它能精准控制哪些字段更新、怎么更新，语义清晰，不易出错。
使用场景：用户资料同步、计数器累加、状态刷新等需要“有则改，无则增”的逻辑。
-
UPDATE子句里不能直接引用被插入的值，要用VALUES(col_name)表达式，例如：UPDATE status = VALUES(status), updated_at = NOW() - 如果主键是自增 ID，而你通过非主键唯一索引触发重复（比如用 email 冲突），
ON DUPLICATE KEY UPDATE依然生效，但要注意影响的是哪一行 - 性能上，它比先
SELECT再判断再INSERT/UPDATE快得多，且避免竞态条件
REPLACE INTO 看似简单，实则暗藏删除重建风险
REPLACE INTO 不是 INSERT 的增强版，而是“删旧 + 插新”两步操作。一旦触发唯一冲突，它会先删除已有行，再插入新行——这会导致自增 ID 变化、外键级联动作、触发器重复执行等问题。
容易踩的坑：在有 AUTO_INCREMENT 主键的表中反复 REPLACE，ID 持续增长；或在外键设了 ON DELETE CASCADE 时，意外删掉关联数据。
- 如果只是想更新几个字段，
REPLACE INTO会把未指定的字段重置为默认值或 NULL，不是保留原值 - 无法区分“第一次插入”和“替换插入”，业务逻辑依赖插入行为做判断时会出问题
- 在高并发写入下，删除+插入的原子性不如
ON DUPLICATE KEY UPDATE可控
批量插入时，IGNORE 和 ON DUPLICATE KEY UPDATE 的行为差异明显
用 INSERT ... VALUES (...), (...), (...) 一次插多行时，IGNORE 是逐行判断、逐行跳过；而 ON DUPLICATE KEY UPDATE 同样逐行处理，但每行可指定不同更新逻辑（靠 VALUES() 区分）。
性能影响：两者都比单条语句快，但 ON DUPLICATE KEY UPDATE 因需解析更多语法，开销略高于 INSERT IGNORE；不过这点差异在大多数业务场景里可忽略。
- 批量插入含重复时，
INSERT IGNORE返回的affected_rows是实际插入的行数（跳过的不计），而ON DUPLICATE KEY UPDATE把插入和更新都算作“affected”，返回总数 - 如果批量中某行因非唯一约束错误失败（比如超长字符串），
INSERT IGNORE仍会继续处理后续行；但ON DUPLICATE KEY UPDATE同样如此——它们都只忽略唯一冲突，不忽略其他错误 - 别指望
INSERT IGNORE能帮你过滤脏数据，它不校验逻辑合理性，只认索引规则
真正难的是预判哪类冲突该跳过、哪类该报错、哪类该合并更新。同一个表，不同业务线可能对“重复”的定义完全不同——有人看 email，有人看 phone+name 组合，有人还要加 tenant_id。索引设计和语句选型得跟着业务语义走，不能光看 SQL 写着顺不顺。
