不能直接用触发器实现软删除数据的同步归档，因为软删除本质是update操作，不触发delete事件，且after update触发器难以可靠识别真实软删除场景，易误归档、不支持跨库、存在死锁与竞态风险。
不能直接用触发器实现软删除数据的同步归档——因为“软删除”本身不触发 DELETE 事件，而触发器只响应 INSERT、UPDATE、DELETE 这三类 DML，不会自动感知字段变更（如 is_deleted = 1）并执行归档逻辑。
为什么 UPDATE 触发器无法可靠捕获软删除
软删除本质是 UPDATE 操作（例如 UPDATE orders SET is_deleted = 1 WHERE id = 123），理论上可用 AFTER UPDATE 触发器监听。但问题在于：
-
OLD.is_deleted = 0 AND NEW.is_deleted = 1这类判断看似合理，但若业务中存在批量更新（如UPDATE ... SET status = 'closed', is_deleted = 1），触发器无法区分“本次更新是否真为软删除”，容易误归档 - 多个字段同时更新时，
OLD和NEW的比较逻辑迅速变得脆弱，且无法覆盖“软删除 + 时间戳写入”等复合场景 - MySQL 不支持在触发器里做子查询去查原表历史状态（比如验证该行此前是否已被软删），否则可能报错 ERROR 1442 或死锁
- 归档动作若放在触发器内（如
INSERT INTO archive_db.orders SELECT * FROM orders WHERE id = NEW.id），会因跨库限制直接失败
正确做法：把归档解耦到应用层或异步任务
真正的软删除归档必须由外部机制驱动，触发器只承担“标记”角色。推荐路径：
- 业务代码执行软删除时，**额外写一条记录到本地
archive_queue表**：INSERT INTO archive_queue (table_name, pk_value, archived_at) VALUES ('orders', 123, NOW()) -
archive_queue表结构要精简（主键、表名、主键值、时间戳、processed布尔字段），避免锁表和写放大 - 用 Python 脚本或
EVENT定时扫描：SELECT * FROM archive_queue WHERE processed = 0 LIMIT 100，然后对每条记录：- 从源表
SELECT *获取当前快照（注意加FOR UPDATE或确认已开启READ-COMMITTED隔离级别） - 检查
is_deleted = 1是否仍成立，防止竞态（如又被恢复） - 写入归档库目标表（确保字段类型完全一致，尤其
TEXT/VARCHAR、TIMESTAMP(6)等） - 更新
archive_queue.processed = 1
- 从源表
- 不要依赖
AFTER UPDATE触发器自动插入archive_queue——除非你严格控制所有软删除都走同一段 SQL，否则极易漏掉
如果坚持用触发器，只能用于单表同库极简场景
仅当满足全部以下条件时，可考虑 BEFORE UPDATE 触发器辅助归档：
- 软删除字段唯一且命名规范（如统一叫
deleted_at，非 NULL 默认为NULL） - 归档目标表与源表在**同一数据库内**（如
orders_archive），且字段类型严格一致 - 归档动作限于单行、小字段（不含
JSON、TEXT大字段），避免锁等待 - 触发器逻辑只做一件事：
IF OLD.deleted_at IS NULL AND NEW.deleted_at IS NOT NULL THEN INSERT INTO orders_archive SELECT * FROM orders WHERE id = NEW.id; - 必须在触发器开头加
IF NOT EXISTS (SELECT 1 FROM orders_archive WHERE id = NEW.id) THEN ... END IF;防止重复归档
这种写法脆弱、难维护、无法扩展，线上环境强烈不建议。
最常被忽略的一点：软删除归档不是“删了再存”，而是“删了之后仍要保证可追溯”。这意味着归档动作必须能处理字段变更、表结构演进、甚至源表被 DROP 后的历史补救——这些能力，触发器天生不具备。
