replace into 不触发 on delete cascade，因其硬删除绕过外键约束检查；但若存在 delete 触发器或 orm 主动清理，可能引发连锁删除；外键未设级联时会直接报错，推荐用 insert ... on duplicate key update 替代。
REPLACE INTO 不触发 ON DELETE CASCADE
这是最常被误解的一点：REPLACE INTO 本质上是「先 DELETE 再 INSERT」，但它**不会触发外键的 ON DELETE CASCADE 行为**。MySQL 官方文档明确指出：REPLACE（含 LOAD DATA ... REPLACE）绕过级联删除逻辑。它执行的是硬删除——直接删掉旧行，不走外键约束检查路径，因此子表记录不会被自动清理。
那为什么还会看到“连锁删除”现象？
真正引发连锁反应的，往往不是 REPLACE INTO 本身，而是它触发的副作用：
- 如果表上定义了
BEFORE DELETE或AFTER DELETE触发器，而这些触发器里写了DELETE FROM child_table WHERE parent_id = OLD.id，那就真会连带删子表——但这属于业务逻辑，和外键无关 - 有人误把
REPLACE INTO当成“安全更新”，在父表执行时没意识到子表仍有残留记录，后续其他操作（比如手动DELETE FROM parent）才真正触发ON DELETE CASCADE，造成“回溯式连锁删除”错觉 - 极少数情况：应用层 ORM 在检测到主表记录被
REPLACE后，主动发起子表清理（例如 Laravel 的->delete()调用链），这也不是数据库行为
外键冲突时 REPLACE INTO 直接失败
当子表存在外键引用，且父表被 REPLACE INTO 删除旧记录时，如果子表未配置 ON DELETE CASCADE 或 ON DELETE SET NULL，MySQL 会直接报错：
Cannot delete or update a parent row: a foreign key constraint fails
这是因为 REPLACE INTO 的「删除阶段」仍受外键约束管控。此时它不会静默跳过，也不会自动级联——它就卡在这一步。
真正该用什么替代 REPLACE INTO？
有外键场景下，REPLACE INTO 是危险且不可控的。更稳妥的选择是：
- 用
INSERT ... ON DUPLICATE KEY UPDATE：只改不删，不触发表级删除逻辑，外键完全不受影响 - 显式分步处理：先
SELECT判断是否存在 → 存在则UPDATE，不存在则INSERT→ 全程可控，可加事务包裹 - 若必须删旧插新，且子表允许清空：先手动
DELETE FROM child WHERE parent_id = ?，再INSERT父表新行 —— 把级联逻辑收归业务层，避免隐式行为
外键的约束力不在语法糖里，而在你是否清楚每一行 DELETE 实际撬动了哪些锁、哪些触发器、哪些关联数据。别让 REPLACE INTO 成为那个你不敢看执行计划的黑盒操作。
