应使用 BEFORE DELETE 触发器而非 AFTER：前者在删除前执行，确保归档成功再删，支持校验拦截；后者原行已删，归档失败会导致删除语句失败且无法回滚。
DELETE 触发器必须用 BEFORE 而不是 AFTER
想在数据删掉之前存一份到归档表，触发器类型选错就全白忙——AFTER DELETE 触发时原行已从主表移除，OLD 仍可用，但若归档逻辑出错（比如归档表字段不匹配、约束冲突），删除语句会直接失败且无法回滚原始操作；而 BEFORE DELETE 在删除动作发生前执行，能确保归档成功才继续删，也方便做校验拦截。MySQL 和 PostgreSQL 都支持 BEFORE DELETE，SQL Server 则需用 INSTEAD OF DELETE 模拟类似行为。
- MySQL 示例：
CREATE TRIGGER backup_before_delete BEFORE DELETE ON orders FOR EACH ROW INSERT INTO orders_archive SELECT OLD.*; - PostgreSQL 注意：不能直接
SELECT OLD.*插入不同结构的表，需显式列出字段，避免因归档表多出archived_at或少字段报错 - SQL Server 不支持
BEFORE，得用INSTEAD OF DELETE+ 手动INSERT INTO ... SELECT+DELETE FROM组合实现，顺序不可颠倒
归档表字段要严格对齐，尤其时间戳和来源标识
只靠 SELECT OLD.* 很容易翻车：归档表若比原表多一个 archived_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP 字段，MySQL 会报 Column count doesn't match value count；如果少一个非空字段，插入直接失败。更关键的是，不加来源标记，后期查归档数据时根本分不清是哪次删除产生的。
- 归档表必须包含与原表完全一致的业务字段（含类型、是否允许 NULL）
- 额外增加至少两个字段：
archived_at DATETIME NOT NULL（记录归档时间）、archived_by VARCHAR(64)（可存触发器名或预留人工标记位） - 插入语句别偷懒，显式写全字段：
INSERT INTO orders_archive (id, user_id, total, archived_at, archived_by) VALUES (OLD.id, OLD.user_id, OLD.total, NOW(), 'trigger_orders_del');
大表删除时触发器会显著拖慢性能，必须加索引和限制条件
单条 DELETE 触发一次归档还行，但 DELETE FROM logs WHERE created_at 这种批量删几百万行的操作，每行都触发一次 <code>INSERT，I/O 和锁竞争会把数据库拖垮。这不是触发器写得不对，而是设计上没考虑吞吐场景。
- 归档表的
archived_at字段必须建索引，否则后续按归档时间查历史快照会极慢 - 禁止在高频删除的大表（如日志、事件流）上直接用行级触发器归档；应改用定时任务 +
INSERT ... SELECT+DELETE分批处理 - 真要用触发器，先在 WHERE 条件里加硬限制：
DELETE FROM orders WHERE id IN (SELECT id FROM orders WHERE status = 'cancelled' LIMIT 1000)，再配合应用层循环，避免单次触发过多归档
事务一致性不能依赖触发器自动保证
很多人以为“触发器和 DELETE 在同一个事务里”，所以归档失败=删除失败，数据不会丢——这没错，但反过来说，归档成功也不代表最终数据安全。比如归档表磁盘满、归档语句被复制延迟卡住（主从架构下）、或归档后主库崩溃未刷盘，都可能导致归档数据丢失而主表已删。
- 触发器内的归档操作受主事务控制，但归档表本身应独立备份策略（如每日 mysqldump 归档库）
- 生产环境务必开启 binlog（MySQL）或 WAL 归档（PostgreSQL），确保归档表变更可重放
- 定期校验：写个脚本比对某天归档数和当天
DELETE行数（通过 general_log 或审计插件捕获），差值非零就得告警
