结论：应优先使用 ON DUPLICATE KEY UPDATE 实现可控 UPSERT；INSERT IGNORE 会静默忽略所有约束错误，无法区分冲突类型；REPLACE INTO 实质是删+插，导致自增 ID 浪费、触发器误执行、外键级联异常及时间戳重置。
直接说结论：别盲目用 INSERT IGNORE 或 REPLACE INTO 处理唯一索引冲突，它们的行为差异大、副作用隐蔽，尤其在有自增主键、触发器、外键或业务逻辑依赖插入结果的场景下，极易出错。
为什么 INSERT IGNORE 会“静默丢数据”
它遇到任何约束冲突（不只是唯一索引，还包括主键、外键、非空、检查约束）都会转为警告并跳过整条语句，不报错也不回滚事务。你无法区分是“重复跳过”还是“字段超长被截断”或“外键不存在”被忽略。
- 常见错误现象：
INSERT IGNORE INTO user(email) VALUES('a@b.c')没反应，查表发现没插入——可能因为email字段被设为NOT NULL但传了NULL，也可能真因重复，但你无从判断 - 性能影响：相比普通
INSERT，它仍要走完整索引查找和冲突检测流程，只是不抛异常；并发高时锁等待时间没减少 - 关键限制：如果表有多个唯一索引，它只要命中任意一个冲突就跳过，无法指定按哪个字段去重
为什么 REPLACE INTO 实际是“删+插”，不是“更新”
REPLACE INTO 不是原子更新操作，而是先尝试插入，冲突时先 DELETE 原记录，再 INSERT 新记录。这会导致：
- 自增主键（
AUTO_INCREMENT）值被浪费：每次REPLACE都会消耗一个新 ID，即使最终只保留一条记录 - 触发器被触发两次：
BEFORE DELETE和BEFORE INSERT都会执行，可能引发意料外的副作用（如日志写入、计数器减/加） - 外键级联失效：若其他表通过外键引用该记录，
DELETE可能触发级联删除，而你本意只是想更新字段 - 时间戳字段重置：
created_at这类默认CURRENT_TIMESTAMP的字段会被重新赋值，丢失原始创建时间
ON DUPLICATE KEY UPDATE 才是可控的“UPSERT”
它真正实现“存在即更新，不存在则插入”，且只基于明确的主键或唯一索引冲突触发，不干扰其他约束，也不会改变主键值或触发删除逻辑。
- 使用前提：目标字段必须有
PRIMARY KEY或UNIQUE KEY索引，否则不生效 - 参数差异：
VALUES(col)引用的是本次INSERT语句中对应列的值，不是原记录值。例如：INSERT INTO t(a,b) VALUES(1,2) ON DUPLICATE KEY UPDATE b=VALUES(b)，更新后的b是2，不是原b加2 - 批量安全：支持一次插入多行，每行独立判断冲突并更新，适合导入场景
- 注意陷阱：如果表有多个唯一索引，只对第一个匹配到的索引生效；若同时存在主键和唯一键冲突，优先按主键判断
空字符串和 NULL 在唯一索引里根本不是一回事
这是最容易被忽略的底层行为。MySQL 中，UNIQUE 索引允许无限个 NULL 值，但只允许一个空字符串 ''。如果你的字段默认设为 ''（而非 NULL），又没做应用层校验，就会出现“看似没填手机号，却因多个 '' 冲突报错”的问题。
- 验证方式：
SELECT COUNT(*) FROM t_user WHERE mobile = '';如果结果 > 1，说明设计或代码已出问题 - 修复建议：把字段默认值改为
NULL，并在应用层统一用NULL表示“未填写”，避免空字符串参与唯一约束 - 兼容性影响：MySQL 5.7+ 默认严格模式下，
''插入NOT NULL字段会直接报错，老版本可能静默转成' '或截断，行为不一致
