MySQL REPLACE 副作用实验：唯一冲突、级联删除与对象身份

把同步脚本里的 INSERT 改成 REPLACE，重复键错误消失了，客户地址却跟着被清空。REPLACE 不是“覆盖指定字段的 UPDATE”：遇到唯一键冲突时，它按删除旧行再插入新行的语义处理，外键删除动作、默认值和对象身份都可能随之改变。

如果业务想表达“同一个客户改个名字”，先把这句话与“旧客户删除后建立一个新客户”分开。SQL 执行成功，不代表这两种操作可以互换。

先看一次只改名字的替换，会动到什么

以下使用 MySQL 8.4、InnoDB 和独立实验库。客户有业务编码与邮箱两个唯一键，地址依赖客户的内部主键。

CREATE DATABASE replace_identity_lab;
USE replace_identity_lab;
CREATE TABLE customer (
    id BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    customer_code VARCHAR(20) NOT NULL,
    email VARCHAR(100) NOT NULL,
    display_name VARCHAR(60) NOT NULL,
    customer_state VARCHAR(20) NOT NULL DEFAULT 'active',
    audit_note VARCHAR(100) NULL,
    UNIQUE KEY uk_customer_code (customer_code),
    UNIQUE KEY uk_customer_email (email)
) ENGINE=InnoDB;
CREATE TABLE customer_address (
    id BIGINT NOT NULL PRIMARY KEY,
    customer_id BIGINT NOT NULL,
    address_text VARCHAR(200) NOT NULL,
    KEY idx_customer (customer_id),
    CONSTRAINT fk_address_customer FOREIGN KEY (customer_id)
        REFERENCES customer(id) ON DELETE CASCADE
) ENGINE=InnoDB;

INSERT INTO customer
    (id, customer_code, email, display_name, customer_state, audit_note)
VALUES
    (1, 'C-01', 'alice@example.test', 'Alice', 'blocked', 'manual review'),
    (2, 'C-02', 'bob@example.test', 'Bob', 'active', NULL);
INSERT INTO customer_address VALUES
    (101, 1, 'address A'), (102, 1, 'address B'), (201, 2, 'address C');

用事务观察替换，再回滚恢复样本：

START TRANSACTION;
REPLACE INTO customer(customer_code, email, display_name)
VALUES ('C-01', 'alice@example.test', 'Alice v2');

SELECT id, customer_code, display_name, customer_state, audit_note
FROM customer ORDER BY id;
SELECT id, customer_id, address_text FROM customer_address ORDER BY id;
ROLLBACK;

需要核对三件具体变化。新记录未指定 id，自增机制会为插入分配编号；未提供 customer_state 和 audit_note，会按新行的默认规则取值；旧客户被删除，指向它的地址按 ON DELETE CASCADE 删除。状态可能从 blocked 回到 active，审计备注也不再是原来那份内容。

这些不是客户端显示的问题，更不是缺少一次 COMMIT。REPLACE 表达的是替换行，应用不能要求它顺便把未指定列理解为“沿用旧值”。

事务回滚可以恢复这里的 InnoDB 数据关系，但已分配的自增编号不需要回收。因此后面再次实验时，不要要求新编号等于某个固定值，也不要为让截图整齐重设编号。

显式 UPDATE 保留的是同一个对象

如果目标只是修改客户名字，按确定业务键更新即可：

UPDATE customer
SET display_name = 'Alice v2'
WHERE customer_code = 'C-01';

SELECT id, display_name, customer_state, audit_note
FROM customer WHERE customer_code = 'C-01';
SELECT * FROM customer_address WHERE customer_id = 1 ORDER BY id;

这次内部 id、状态、备注和地址关系都不应因改名而重新生成。SQL 列表里只出现 display_name，也让审核者能够理解修改范围。

更新不存在记录时该报错、忽略还是新增，则是另一个业务决定。不能为了同时支持两种情况，就使用会删除旧对象的语义作为未经评估的快捷方式。

需要插入或更新时，MySQL 8.4 可以用 ON DUPLICATE KEY UPDATE，并明确只改哪些列。以下采用新行别名，不依赖旧的 VALUES(column) 写法：

INSERT INTO customer(customer_code, email, display_name)
VALUES ('C-01', 'alice@example.test', 'Alice v3') AS incoming
ON DUPLICATE KEY UPDATE display_name = incoming.display_name;

但它也不是所有多唯一键模型的通用解法。冲突可能来自 customer_code，也可能来自 email；如果两项指向不同的已有客户，必须先解决身份冲突，不能让“命中了某个唯一键”替业务决定更新谁。

两个唯一键冲突，可能牵涉不止一条旧行

在事务里构造一个明确的身份冲突：客户编码用 Alice 的，邮箱却用 Bob 的。

START TRANSACTION;
REPLACE INTO customer(customer_code, email, display_name)
VALUES ('C-01', 'bob@example.test', 'conflicting replacement');

SELECT id, customer_code, email, display_name FROM customer ORDER BY id;
SELECT id, customer_id FROM customer_address ORDER BY id;
ROLLBACK;

REPLACE 为插入新行消除唯一冲突时，可以删除被不同唯一键命中的多条旧行。因此“替换一行”不等于只可能涉及一个旧对象，关联地址也可能不只清理 Alice 的部分。

这类输入通常应该被识别为数据冲突，而不是自动合并。一个编码和另一个邮箱指向两个客户，究竟谁拥有哪份身份，需要业务证据。数据库无法从一条 REPLACE 中推断合法合并规则。

受影响行数也不能简单用来统计“成功新增客户数”。REPLACE 的计数包含删除与插入，可能大于一；多唯一冲突还会改变涉及的旧行数量。日志若只记录“写入一条”，会掩盖真正发生的身份替换。

即便显式保留原 id，删除副作用也不会消失

有些修补会先查旧 id，再把它填进 REPLACE，认为这样地址就能保住。这个推断忽略了删除动作：旧行先被删除时，外键级联已经可以执行；后来重新插入相同编号，也不会自动把已经删除的子记录复活。

先查 id 再写，还增加了并发窗口。查询之后对象可能发生变化，或者另一个唯一键冲突指向不同对象。给 REPLACE 补更多旧字段，通常只是把一条含义不合适的语句变成一段更脆弱的模拟更新。

若下游通过主键识别对象，重新生成 id 会表现为旧对象消失和新对象出现；若只看业务编码，又可能把这种身份更换误认为普通字段更新。缓存、搜索索引和审计需要的事件语义也会不同。

触发器与外键同样要分别核对。显式删除和插入可以触发各自的触发器规则，而外键级联对子表不等同于应用直接执行 DELETE。不能假定现有子表审计覆盖了所有级联路径。

可以继续在恢复后的样本上验证“保留同一个 id”并不能保住地址：

START TRANSACTION;
REPLACE INTO customer
    (id, customer_code, email, display_name, customer_state, audit_note)
VALUES
    (1, 'C-01', 'alice@example.test', 'Alice same id',
     'blocked', 'manual review');
SELECT * FROM customer_address WHERE customer_id = 1;
ROLLBACK;

这条语句甚至把原状态和备注都补回来了，子对象删除仍然是必须关注的副作用。由此可见，逐列补齐旧字段只能解决默认值覆盖，不能把替换语义变成原地更新。

验收若只比较父表主键和值，就可能漏掉这次损失。对于带依赖对象的写入，应同时核对关系集合；哪怕父表最终看起来完全相同，子表已经可能不同。缓存里仍保留旧地址，还会让问题在一段时间内不容易被用户发现，之后缓存失效才集中暴露。

修复这类事故也不应盲目重放所有旧地址。替换发生以后可能已经有用户新增或删除地址，需要按实际事件时间线和对象标识校正，避免用旧备份覆盖新的合法修改。保留变更日志和受影响客户集合，会比单纯记录一条成功 SQL 更有恢复价值。

同步脚本应该先声明数据属于谁

当上游提供完整快照时，下游也未必应该删除重建对象。本地可能保存风控状态、审核备注和用户维护字段，上游并不拥有这些字段。REPLACE 省略它们后按默认值重建，会把所有权边界抹掉。

更容易解释的同步规则是明确上游可修改列、本地保留列、缺失值含义和冲突处理。普通 UPDATE 或经过身份核对的 upsert 可以表达窄修改，但仍应受唯一键和业务状态规则约束。

如果业务确实需要删除再重建，应把它作为显式动作评审：哪些子对象被删除，哪些需要保留或迁移，旧标识是否仍允许外部引用，失败时如何恢复。此时 REPLACE 可以是实现候选，不能再被称为“无副作用更新”。

从已有脚本迁走，要核对的不只是语句文本

先找到实际调用的表和唯一键，列出 REPLACE 未提供但当前行会保存的字段。再用带非默认状态、存在子记录、两个唯一键分别冲突的样本，运行旧逻辑与候选逻辑对照。

验收不要只看最终名字正确。核对主键是否保留、地址是否完整、风控状态和审计备注是否一致，并检查下游如何解释这次变更。正是那些没出现在同步文件里的字段，最容易在替换语义中丢失。

并发测试还应覆盖同一客户重复同步，以及一项身份标识被另一个对象占用。冲突需要返回可处理结果，不能自动退回 REPLACE 作为“保证成功”的兜底。那会在异常路径重新引入已修掉的删除副作用。

实验结束时，前面的三个替换事务都已经回滚，只有 UPDATE 和窄字段 upsert 的改名操作保留。最后核对 Alice 的身份和地址：

SELECT c.id, c.customer_code, c.display_name,
       c.customer_state, c.audit_note, a.id AS address_id
FROM customer AS c
LEFT JOIN customer_address AS a ON a.customer_id = c.id
WHERE c.customer_code = 'C-01'
ORDER BY a.id;