别再乱用REPLACE INTO了！MySQL里实现‘有则更新，无则插入’的正确姿势（附避坑指南）

MySQL高效数据写入：深入解析REPLACE INTO与ON DUPLICATE KEY UPDATE的实战差异

1. 从真实案例看REPLACE INTO的隐藏风险

去年夏天，我们的电商平台遭遇了一次诡异的数据丢失事件。在促销活动期间，用户积分表的累计值频繁出现归零现象。技术团队排查三天后，最终发现问题出在一段看似无害的SQL语句上：

REPLACE INTO user_points(user_id, total_points) 
VALUES (12345, 100);

开发者的本意是"如果用户存在则更新积分，不存在则插入"。但实际执行时，每当用户已有记录，REPLACE INTO会先 完全删除旧记录 再插入新记录。这导致关联的积分明细表因外键约束而级联删除——用户几个月积累的积分历史瞬间清零。

更糟糕的是，当表有多个唯一索引时：

CREATE TABLE products (
    id INT PRIMARY KEY,
    sku VARCHAR(20) UNIQUE,
    stock INT
);

-- 危险操作！
REPLACE INTO products(id, sku, stock) 
VALUES (1, 'IPHONE_13', 10);

如果sku='IPHONE_13'已存在但id不同，MySQL会删除 所有冲突行 。我们曾因此一次性损失了三条产品记录，引发库存系统混乱。

2. 解密REPLACE INTO的工作原理

通过EXPLAIN分析REPLACE INTO的执行计划，会发现它本质上是两个操作的组合：

1. 隐式DELETE ：根据主键或所有唯一索引匹配记录
2. 标准INSERT ：插