做数据开发的同学，十有八九都遇到过这种需求：某张表里，数据存在就更新，不存在就插入。MySQL里最直接能想到的语法，就是REPLACE INTO。这语法用起来简单，一句SQL就能搞定“有则更新、无则插入”，但很多人不知道，它背后的执行逻辑是“先删后插”，坑埋得特别深。
这篇文章我把REPLACE INTO从语法、原理到实际场景，再到各种翻车案例完整拆一遍。如果你正在负责数据同步、批处理写入、或者接口幂等落库这类任务，花几分钟看完，能少走不少弯路。
1. REPLACE INTO 到底是什么：语法与执行原理
1.1 基本语法与写法
REPLACE INTO的写法和INSERT INTO几乎一样，最简单的形式是这样：
REPLACE INTO user (id, name, age) VALUES (1, '张三', 18);也可以一次写入多行：
REPLACE INTO user (id, name, age) VALUES (1, '张三', 18), (2, '李四', 20), (3, '王五', 22);还能用SET写法：
REPLACE INTO user SET id = 1, name = '张三', age = 18;从语法上看，REPLACE就是把INSERT换了个关键字，其他几乎一样。但执行语义完全不同。如果以为REPLACE INTO就是“不存在插入、存在就更新”，那只是看到了表面。它的底层逻辑是：先尝试插入，如果因为主键或唯一索引冲突插入失败，就删除掉那条冲突的记录，再插入一条全新的记录。
也就是说，看似是“更新”，实际是“删旧插新”。
1.2 执行背后：MySQL 到底做了什么
我们拿一张最简单的表来看：
CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(50) DEFAULT NULL, `age` int(11) DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_name` (`name`) ) ENGINE=InnoDB;假设现在表里有这样一条数据：
| id | name | age |
|---|---|---|
| 1 | 张三 | 18 |
执行REPLACE INTO user (id, name, age) VALUES (1, '张三', 20);时，MySQL 做的事是：
- 尝试插入一条
(1, '张三', 20)的记录。 - 发现主键
id=1冲突，于是删除原有那条id=1的记录。 - 重新插入
(1, '张三', 20)。
表面看数据变成了(1, '张三', 20)，好像只是改了年龄。但内部流程里** DELETE 和 INSERT 是实打实执行了的**。
这里有几个关键影响，很多人在使用中完全没意识到：
- 如果表上有自增主键，
REPLACE会消耗一个新的自增ID。即使只改了年龄，ID的增长也会继续往前跳。频繁REPLACE，自增ID会涨得飞快。 - 如果表上有外键关联，删除操作会触发级联删除（或报错，取决于外键约束配置），子表数据可能被连带删掉。
- 如果表上有DELETE触发器，REPLACE时会触发DELETE触发器，而不是UPDATE触发器。这点后面单独讲。
- 如果表上有多个唯一索引，需要特别注意。只要任何一个唯一索引冲突，就会触发删除。更麻烦的是，如果有多行记录分别和不同唯一索引冲突，MySQL会删除多行再插入新行。
我见过一个真实的案例：一张表同时有uk_order_no（订单号唯一）和uk_batch_no（批次号唯一），业务上用REPLACE INTO按订单号更新，结果某次数据里新批次号和另一条老记录的批次号冲突，一条REPLACE语句一口气把两条记录全删了，再插入一条新数据。线上的账单明细直接少了一行，排查了半天才找到原因。
2. 为什么这么多人拿它做“不存在插入、存在更新”
2.1 适用场景与 upsert 语义
REPLACE INTO最典型的应用场景，就是各类增量同步和状态上报：
- 数据仓库同步业务库的变更记录，按主键覆盖写入。
- 埋点上报按设备ID+日期维度做覆盖更新。
- 接口幂等落库，按业务唯一键保证不重复插入。
- 配置表初始化脚本，多次执行不会产生重复数据。
这些场景有个共同点：业务上不关心“更新”动作本身，只关心最终状态对不对。所以“删了再插”虽然多消耗一点性能，但在数据量可控的情况下，写起来确实很爽。
比如要同步一个订单状态表，业务侧的变更记录一天有几万条，直接这样写：
REPLACE INTO dwd_order_info (order_id, status, update_time) VALUES ('20241015001', 'PAID', NOW());下次再来一条同订单号的记录，不管之前是什么状态，直接覆盖成最新状态。逻辑简单，SQL短，不用先SELECT判断是否存在，也不用拆成UPDATE和INSERT两条语句。
这也是很多人初次接触REPLACE INTO时觉得“真好用”的原因——一条语句解决了判断+写入的所有逻辑。
2.2 批量更新场景怎么用
REPLACE INTO支持多值批量写入，所以在做批量“有则更新、无则插入”时特别顺手。比如把一批订单的最新状态刷进去：
REPLACE INTO dwd_order_info (order_id, status, update_time) VALUES ('20241015001', 'PAID', '2024-10-15 18:00:00'), ('20241015002', 'SHIPPED', '2024-10-15 18:05:00'), ('20241015003', 'COMPLETED', '2024-10-15 18:10:00'), ('20241015004', 'CANCELLED', '2024-10-15 18:12:00');一次写几百行、几千行都可以，MySQL会逐条尝试插入，遇到冲突就删旧插新。相比逐条执行，批量SQL大幅减少了网络交互和SQL解析开销，写入吞吐明显提升。
不过有个点要特别注意：真正执行时，MySQL仍然是逐行处理的。它不是“只对冲突行做更新”，而是每一行都尝试验插入，冲突才触发删除。所以批量REPLACE的性能并不是无限扩展的，几千行一批基本是合理区间，单条SQL塞几万行会导致锁范围过大、binlog体积暴涨，线上容易出问题。
实际经验是：单批控制在 1000~2000 行，执行时间、锁占用、主从延迟都比较可控。
3. REPLACE INTO 的坑：每一个都值得你提前知道
3.1 未指定字段被重置为默认值
这是所有REPLACE INTO使用者最容易踩的坑，而且往往是在线上出了事故才反应过来。
比如表结构：
CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(50) DEFAULT NULL, `phone` varchar(20) DEFAULT NULL, `age` int(11) DEFAULT NULL, `status` tinyint(4) DEFAULT '1', PRIMARY KEY (`id`) ) ENGINE=InnoDB;原有数据：(1, '张三', '13800000000', 18, 1)。
如果我执行：
REPLACE INTO user (id, name, age) VALUES (1, '张三', 20);你猜结果是什么？
直觉上可能是“只更新 age”，但真实结果是：
| id | name | phone | age | status |
|---|---|---|---|---|
| 1 | 张三 | NULL | 20 | 1 |
因为它是先删除原记录，再插入新记录，新记录里没写的字段，全部走了DEFAULT。原本好好的电话号码，直接变成了NULL。
在业务开发中，这种问题特别隐蔽。如果接口层拿到了完整字段还好，如果是部分更新，用REPLACE INTO就相当于把没传的字段全部清空了。我曾经排查过一个用户资料数据异常的问题：用户头像、昵称、签名时不时消失，最后定位到就是某处调用用了REPLACE INTO，只传了用户ID和修改字段，结果其他字段全被重置成默认值。这种坑，不是业务报错，数据看起来也不是完全错误，最容易被忽视。
注意：如果业务是部分字段更新，一定要避免使用 REPLACE INTO。要么先SELECT出来补全字段，要么直接用 UPDATE 或 ON DUPLICATE KEY UPDATE。
3.2 自增ID暴涨，主键越涨越离谱
因为REPLACE INTO的实质是删除+插入，自增主键每次都会分配一个新的ID。
举个例子：
INSERT INTO user (id, name, age) VALUES (1, '张三', 18); -- 此时自增ID变为2 REPLACE INTO user (id, name, age) VALUES (1, '张三', 20); -- 删除id=1，插入新记录，新记录id=2，自增ID变为3 REPLACE INTO user (id, name, age) VALUES (2, '张三', 22); -- 删除id=2，插入新记录，新记录id=3，自增ID变为4也就是说，每次 REPLACE 都会消耗一个新的自增ID，哪怕只是改一个字段的值。这种情况下，ID的增速是实际业务量的几倍甚至几十倍。
带来的问题有：
- 主键很快超出
INT范围（如果用的是int(11)）。 - 表占用的磁盘空间增加，索引体积变大。
- 数据同步场景中，ID断层严重，下游依赖ID做增量判断的逻辑会出问题。
如果你在做一个订单表，每天REPLACE几千次，ID从1涨到几万，这还算能忍。但如果批量循环REPLACE，一天操作几十万次，ID可能要不了多久就逼近INT上限了。
注意：凡是依赖自增ID做业务语义、或需要保持ID连续的场景，都不适合用 REPLACE INTO。
3.3 触发器行为和你想象的不一样
如果表上有触发器，会导致更大的问题。
REPLACE INTO是通过删除+插入来完成的，所以它触发的不是UPDATE触发器，而是DELETE触发器和INSERT触发器。
假设你有一张审计日志表，希望字段变化时自动记录到日志表。如果用REPLACE INTO，那每次执行时：
DELETE触发器被调用：记录一条“删除了id=1的数据”。INSERT触发器被调用：记录一条“插入了id=1的数据”。
日志里不会看到“更新了id=1的数据”，而会看到“删除+新增”两条记录。
更严重的是，如果 DELETE 触发器里有业务逻辑，比如级联删除关联表、同步给下游、累计变更次数，这些逻辑都会被触发。如果这个触发器本身又对同一张表做操作，还可能引发递归或死锁。
有一个真实的教训：团队给一张主表加了AFTER DELETE触发器，逻辑是删除主表记录时同步删除子表关联数据。某次用REPLACE INTO修改主表数据，结果把子表关联数据全删了。排查问题的时候，大家盯着 UPDATE 语句看半天，根本想不到问题出在触发器上。
注意：使用 REPLACE INTO 之前，先检查表上有哪些触发器，特别是 DELETE 触发器。如果有，尽量别用 REPLACE。
3.4 多个唯一索引时的“误伤”
表上如果有多个唯一索引，REPLACE INTO的判定逻辑会变得很危险。
看这张表：
CREATE TABLE `order_item` ( `id` int(11) NOT NULL AUTO_INCREMENT, `order_no` varchar(32) DEFAULT NULL, `item_no` varchar(32) DEFAULT NULL, `amount` decimal(10,2) DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_item` (`order_no`, `item_no`) ) ENGINE=InnoDB;如果只有业务联合唯一键uk_order_item，那 REPLACE 的行为相对可控：按(order_no, item_no)判定冲突。
但如果有多个独立唯一键：
CREATE TABLE `order_info` ( `id` int(11) NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL, `trace_no` varchar(32) NOT NULL, `status` varchar(20) DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`), UNIQUE KEY `uk_trace_no` (`trace_no`) ) ENGINE=InnoDB;执行：
REPLACE INTO order_info (order_no, trace_no, status) VALUES ('A001', 'T002', 'PAID');如果表里已经存在一条order_no='A001'的记录，同时存在另一条trace_no='T002'的记录，MySQL会把这两条都删除，然后插入新记录。
原因是：REPLACE在插入时遇到任何唯一索引冲突，都会把对应的行删除。多个冲突时，逐行删除，最后插入新行。
结果就是：一次本想更新一条数据的操作，实际删掉了两条。
这种“误伤”在生产环境会导致严重的数据漂移。更好的做法是：只保留一个业务唯一键，或者不用 REPLACE 而改用INSERT ... ON DUPLICATE KEY UPDATE。
注意：有多个唯一索引的表，慎用 REPLACE INTO。建议先梳理业务上的唯一键约束，必要时用 ON DUPLICATE KEY UPDATE 代替。
4. 备选方案对比：REPLACE INTO 和 ON DUPLICATE KEY UPDATE 怎么选
4.1 行为差异对照
既然 REPLACE 有这么多坑，那就引出了最经典的对比对象：INSERT ... ON DUPLICATE KEY UPDATE。
两者的目的都是“不存在插入、存在更新”，但实现思路完全不同。
| 对比项 | REPLACE INTO | INSERT ... ON DUPLICATE KEY UPDATE |
|---|---|---|
| 实现方式 | 删除+插入 | 插入失败后执行 UPDATE |
| 未指定字段 | 重置为默认值 | 保留原值 |
| 自增ID消耗 | 每次消耗一个新ID | 冲突时消耗一个新ID，但更新不产生新记录（但会耗尽自增ID？实际仍会消耗） |
| 触发器 | DELETE + INSERT 触发器 | UPDATE 触发器 |
| 多个唯一索引冲突 | 可能删除多行 | 只更新一行 |
| 性能 | 需要 DELETE + INSERT，开销更大 | 需要 UPDATE 操作，开销较小 |
| 外键风险 | 可能触发级联删除 | 相对较低 |
这里重点说下ON DUPLICATE KEY UPDATE的写法：
INSERT INTO user (id, name, age) VALUES (1, '张三', 20) ON DUPLICATE KEY UPDATE name = '张三', age = 20;如果不冲突，正常插入；如果主键或唯一索引冲突，则执行 UPDATE 子句。未被涉及到的字段保持原值不变，这和 REPLACE 的“删旧插新”有本质差异。
比如说前面那个例子，原记录phone='13800000000'，执行：
INSERT INTO user (id, name, age) VALUES (1, '张三', 20) ON DUPLICATE KEY UPDATE name = '张三', age = 20;结果 phone 还是原来的值，不会变成 NULL。
还有一点值得注意：ON DUPLICATE KEY UPDATE也可以做批量：
INSERT INTO user (id, name, age) VALUES (1, '张三', 20), (2, '李四', 22) ON DUPLICATE KEY UPDATE name = VALUES(name), age = VALUES(age);批量场景一样支持，而且比 REPLACE 更安全。
4.2 场景选择建议：该用哪个
用哪个，取决于你到底想干什么。
如果业务上只需要保留完整的最新快照，比如数据仓库的拉链表更新、维度表的全量覆盖，REPLACE INTO 的“删旧插新”恰恰能保证表的最终状态绝对干净——多余的字段不会残留，被逻辑删除的记录也会被物理清除。这种情况下 REPLACE 反而简单直接。
如果业务上是针对部分字段的更新，比如用户资料修改、订单状态流转，强烈建议用INSERT ... ON DUPLICATE KEY UPDATE。因为它保留未涉及字段的原有值，不会造成隐性数据丢失。
此外，如果你在意自增ID的稳定性和主从延迟，ON DUPLICATE KEY UPDATE更友好。
我个人的选择逻辑是：
- 表有
updated_at且业务关心更新时间，用ON DUPLICATE KEY UPDATE。 - 表的字段都是强制覆盖，且无外键、无DELETE触发器，用
REPLACE INTO问题不大。 - 有多个唯一索引，宁可写复杂一点的
ON DUPLICATE KEY UPDATE，也别赌 REPLACE 不会误删。
注意：高并发场景下，无论选哪种，都要注意唯一键冲突时的锁等待和死锁问题。写入前尽量保证数据是“可插入”的，否则 ON DUPLICATE 也可能因死锁报错。
5. 实操指南：不同场景下的推荐用法
5.1 数据同步场景：用 REPLACE 还是 ON DUPLICATE？
如果你负责把A库的业务表同步到B库的数仓表，每天全量或增量覆盖，推荐这样：
REPLACE INTO dwd_user_snapshot (user_id, name, phone, status, update_time) SELECT user_id, name, phone, status, update_time FROM ods_user_info WHERE update_time >= '2024-10-15 00:00:00';这种场景本质上是“整行覆盖”，目标表不需要保留原记录的任何额外信息，REPLACE 的“删旧插新”和源数据保持一致，不会有问题。
如果同步的目标表里还有手工维护的字段，比如数仓里面的etl_remark、is_manual，那就不能用 REPLACE 了，会把手动维护的字段清空。这种用 ON DUPLICATE 更合理：
INSERT INTO dwd_user_snapshot (user_id, name, phone, status, update_time) SELECT user_id, name, phone, status, update_time FROM ods_user_info WHERE update_time >= '2024-10-15 00:00:00' ON DUPLICATE KEY UPDATE name = VALUES(name), phone = VALUES(phone), status = VALUES(status), update_time = VALUES(update_time);这样etl_remark字段不会被触碰。
5.2 批量写入优化：如何把 REPLACE 写出高性能
批量REPLACE时，有几个实操细节：
1. 控制批量大小。500到2000行一批是性价比最好的区间。太小了网络交互太多，太大了锁范围和undo日志膨胀，反而拖慢性能。
2. 尽量让冲突比例低。如果一批数据大部分是已存在的旧数据，REPLACE会频繁触发删加操作，性能会明显下降。这种情况下不如先查出来，只处理真正变化的行。
3. 关闭自动提交或者使用事务包裹。
START TRANSACTION; REPLACE INTO t_order (order_id, status) VALUES ('A001', 'PAID'), ('A002', 'SHIPPED'); COMMIT;事务包裹可以避免每条REPLACE单独提交带来的大量磁盘fsync，大批量写入时性能提升非常明显。
4. 考虑低峰期执行。REPLACE 会持有行锁、间隙锁，如果目标表正在被大量读写，建议把批量任务放到低峰期，或者在业务侧做限流。
5.3 幂等写入场景：REPLACE 之外更好的选择
接口幂等落库，其实还有比 REPLACE 更稳的写法。
比如你用分布式ID作为主键，业务上想到达到“同一个请求ID只落一条数据”，可以直接用：
INSERT INTO t_request_log (request_id, content, create_time) VALUES ('req_001', '...', NOW()) ON DUPLICATE KEY UPDATE content = VALUES(content);这已经处理了重复请求覆盖的问题。但如果你想完全避免重复插入，还可以用INSERT IGNORE：
INSERT IGNORE INTO t_request_log (request_id, content, create_time) VALUES ('req_001', '...', NOW());INSERT IGNORE遇到唯一键冲突时直接忽略，不报错也不覆盖，适合“只允许第一条生效”的场景。
如果既要“重复就忽略”，又要在某些字段更新，ON DUPLICATE KEY UPDATE才是正解。
如果业务并发写很高，还可以在应用层做一层去重，比如基于 Redis 的 SETNX，先判断是否已处理，再写库。数据库层的唯一索引兜底，防止极端情况下的重复写入。
6. 常见问题与排查技巧实录
6.1 现象：数据量不大，但自增ID已经大到离谱
很多团队遇到表的主键ID几亿、几十亿，但实际数据量只有几万行。排查时发现，罪魁祸首就是REPLACE INTO用得太多。
每条 REPLACE 都会让自增ID加1，频繁的覆盖更新让ID迅速膨胀。
排查方法：
- 看
information_schema.TABLES里的AUTO_INCREMENT值。 - 看 binlog 或慢查询日志里
REPLACE INTO的执行频率。 - 如果确认是 REPLACE 导致的，方案是改用
ON DUPLICATE KEY UPDATE，并用ALTER TABLE ... AUTO_INCREMENT=...修正ID（如果业务允许）。
6.2 现象：更新之后，有些字段变成了默认值
这个前端反馈“我明明传了手机号，存进去却是空的”，其实后台SQL只用REPLACE INTO传了ID和姓名，其他字段没带，就全被重置了。
排查方式：
- 查看慢日志或审计日志里针对这张表的写操作SQL。
- 确认是不是 REPLACE 语法，再看字段列表是否完整。
- 最快的修复：把 REPLACE 改成 ON DUPLICATE KEY UPDATE，只更新需要变更的字段。
注意：做代码审查时，看到
REPLACE INTO就多问一句：“这条语句会覆盖哪些字段？没写的字段怎么办？”能避免很多线上事故。
6.3 现象：主表更新后，子表数据不见了
这个多半和 DELETE 触发器有关，或者外键级联删除。
排查方法：
- 查表上的触发器：
SHOW TRIGGERS LIKE 'table_name'; - 看外键约束：
SHOW CREATE TABLE table_name; - 如果是 DELETE 触发器或外键级联，把 REPLACE 替换成 UPDATE 或 ON DUPLICATE KEY UPDATE，避免触发 DELETE 路径。
6.4 现象：REPLACE 报错“Duplicate entry”
有时候你以为 REPLACE 就是用来解决重复的，但它反而报 Duplicate entry。
这种情况通常是：表里有多个唯一键，且新插入的数据和不同行的唯一键冲突。MySQL 删除冲突行的时候，发现新数据又和另一行冲突，处理顺序不同可能会报错。
比如执行：
REPLACE INTO order_info (order_no, trace_no, status) VALUES ('A001', 'T002', 'PAID');插入时发现order_no='A001'和trace_no='T002'分别对应两条已有记录，REPLACE 会把两条都删除再插入新行。如果其中一条记录正好被其他事务锁住，就可能报错或死锁。
解决方案依然是：避免多唯一键表使用 REPLACE，改为INSERT ... ON DUPLICATE KEY UPDATE，并确认业务上真正的唯一键是哪个，表结构尽量只保留一个业务唯一键。
6.5 一个附加的排查技巧
查历史 REPLACE 语句执行记录时，有个好用的小技巧——在 MySQL 的慢查询日志里搜关键字：
grep -i "replace into" slow-query.log或者用information_schema看最近执行过的语句，配合performance_schema：
SELECT * FROM performance_schema.events_statements_history_long WHERE SQL_TEXT LIKE 'REPLACE%' ORDER BY TIMER_START DESC LIMIT 20;用这个方式定位到具体是谁在跑 REPLACE，再决定要不要改。
一个重要但常被忽略的细节：binlog 和主从延迟
使用REPLACE INTO还有一个容易被忽略但生产环境很致命的问题：binlog日志膨胀和主从延迟。
REPLACE INTO的二进制日志默认是STATEMENT格式时，记录的是REPLACE语句本身，日志量看起来不大。但如果 binlog 格式是ROW（也就是现在 MySQL 默认推荐的格式），情况就完全不同了：
- 对于每条 REPLACE，binlog 会记录一条DELETE 事件加一条INSERT 事件。
- 如果批量 REPLACE 了 2000 行，binlog 里会记录约 2000 条 DELETE 事件和 2000 条 INSERT 事件。
这意味着什么？意味着同样一次业务写入，binlog 产生的日志量可能比普通 UPDATE 大好几倍。大量 binlog 同步到从库，从库的 SQL 线程执行时会把每条 DELETE 都重新执行一遍，导致主从延迟明显加大。
我有一次跑数据修复任务，用 REPLACE INTO 批量覆盖了十几万行数据，主库执行时间其实还好，但 binlog 写完直接占了好几个GB，从库延迟从几秒一路涨到几十分钟。因为从库要“真实删除+重新插入”十几万行，除非索引和机器性能足够强，否则延迟会持续很久。
如果你在维护一套主从架构，且对从库的实时性有要求（比如读写分离读从库），REPLACE INTO 的日志放大效应必须考虑。
如果想降低影响，有两个思路：
- 用
INSERT ... ON DUPLICATE KEY UPDATE代替 REPLACE，binlog 里只记录一条 UPDATE 事件（ROW 格式下也只记录变更前后的行镜像），日志量小很多。 - 如果确实必须用 REPLACE，尽量把大事务拆成小批量，每批千行左右提交，避免一次性产生超大 binlog 事件，给从库留出追平的时间。
另外，还有一个小细节：REPLACE INTO在 ROW 格式 binlog 下，从库执行 DELETE 事件时，如果表上没有定义主键或唯一索引，可能会因为找不到匹配行而报错或跳过，这种数据不一致问题排查起来非常痛苦。所以，使用 REPLACE 的表必须有明确的主键或唯一索引。
写在最后：我现在的用法和判断逻辑
讲了一堆 REPLACE INTO 的原理和坑，最后说说我现在的实际使用习惯。
前几年我确实很喜欢用它，因为写起来真的太省事了。但从第一次线上事故（子表数据被触发器删光）以后，我给自己立了一条规矩：凡是涉及多条字段、带外键、带触发器、有自增ID强依赖的表，一律不碰 REPLACE，统一改成 INSERT ... ON DUPLICATE KEY UPDATE。
REPLACE INTO 如今在我这里是有限场景的专用工具：
- 拉全量数据的数仓快照表，整行覆盖，不要保留额外字段，这时 REPLACE 没毛病。
- 临时表或中间表的自清理逻辑，REPLACE 能快速收敛状态。
- 不关心自增ID、没有触发器、没有外键的底层基础表，REPLACE 可以省很多事情。
如果拿不准，先写一条ON DUPLICATE KEY UPDATE。它不会删除数据，不会触发 DELETE 触发器，不会重置未涉及的字段，行为比 REPLACE 可预期得多。习惯了之后，你会发现绝大多数场景里它都是更好的那个选项。
最后分享一个小技巧：上线之前，把项目里所有replace into关键字搜一遍，逐个确认使用场景是否满足上面说的安全条件。这一搜，经常能搜出一两个隐患。等项目跑了一段时间再去翻历史踩坑记录，你就知道这个动作有多值了。
