insert ... on duplicate key update 是最直接的解法,能在主键或唯一索引冲突时自动转为更新,前提是表必须有明确的唯一约束,否则不生效。

INSERT ... ON DUPLICATE KEY UPDATE 是最直接的解法
MySQL 中 INSERT ... ON DUPLICATE KEY UPDATE 能在主键或唯一索引冲突时自动转为更新,避免报错且保证单条记录最终状态确定。前提是表必须有明确的唯一约束(如 PRIMARY KEY 或 UNIQUE 索引),否则该语法不生效。
常见错误是只加了业务字段索引但没设 UNIQUE,导致重复插入仍成功——务必检查 SHOW CREATE TABLE 输出中对应字段是否有 UNIQUE KEY。
示例:
INSERT INTO users (id, name, email) VALUES (1, 'Alice', 'a@example.com') ON DUPLICATE KEY UPDATE name = VALUES(name), email = VALUES(email);
注意:VALUES(col) 引用的是本次 INSERT 的值,不是当前行旧值;若想保留旧值(比如不覆盖已有的更新时间),就得显式写成 updated_at = IF(VALUES(id) = id, updated_at, NOW()) 这类逻辑。
REPLACE INTO 会删再插,慎用于有外键或触发器的场景
REPLACE INTO 表面看也幂等,但它底层是先 DELETE 再 INSERT。这意味着:如果表被其他表外键引用(且未设 ON DELETE CASCADE),会直接报错;若有 BEFORE/AFTER INSERT 触发器,会被执行两次(一次删、一次插);自增 ID 也可能跳变。
仅当满足以下全部条件时才考虑它:
- 表无外键依赖
- 无敏感触发器逻辑
- 能接受自增 ID 不连续
示例:
REPLACE INTO configs (key_name, value) VALUES ('site_title', 'My Site');
INSERT IGNORE 只跳过冲突,无法控制更新行为
INSERT IGNORE 遇到唯一键冲突就静默忽略整条语句,不报错也不更新。它适合“只确保存在、不关心是否最新”的场景,比如初始化默认配置项。
但一旦你希望某字段(如 last_modified)随每次运行而刷新,INSERT IGNORE 就失效了——它连更新都不做。此时必须换用 ON DUPLICATE KEY UPDATE 或事务+SELECT判断。
容易踩的坑:IGNORE 也会吞掉其他非唯一约束错误(如字段长度超限、NOT NULL 违反),掩盖真实问题。生产环境建议只在明确知道只会遇到唯一冲突时使用。
用 SELECT + 事务兜底适用于复杂条件或跨字段幂等
当幂等依据不是单个唯一键,而是多个字段组合(如 (tenant_id, feature_name)),或需根据已有值做条件更新(如“仅当当前状态为 draft 时才允许插入”),ON DUPLICATE KEY UPDATE 就不够用了。
这时得用显式事务:
BEGIN; SELECT id FROM rules WHERE tenant_id = 123 AND feature_name = 'login_rate_limit' FOR UPDATE; -- 若查到,UPDATE;若没查到,INSERT; COMMIT;
关键点:FOR UPDATE 防止并发写入导致重复插入;必须用 BEGIN/COMMIT 包裹,不能只靠单条语句;应用层要处理 SELECT 返回空的情况。PostgreSQL 用户可改用 INSERT ... ON CONFLICT DO UPDATE,语义更清晰。
真正难的不是语法选择,而是厘清“什么才算一致”:是记录存在即可?还是字段值必须精确等于某次输入?抑或要按业务规则合并?不同定义对应不同实现,别让“幂等”变成一句模糊的安慰。











