<p>可行，但必须用 BEFORE DELETE 触发器读取 OLD.* 安全归档；AFTER 中操作同表会触发 MySQL 错误 1442；批量删除应弃用触发器，改用应用层分步归档。</p>
DELETE 触发器里直接 INSERT 归档表可行吗
可行，但必须确保归档表结构与源表兼容，且触发器内不能引用被删除行的 AFTER 状态字段（比如自增 ID 在 BEFORE DELETE 中仍可读，AFTER 中已不可见）。最稳妥的是用 BEFORE DELETE ——此时 OLD.* 完整可用，能安全取值插入归档表。
常见错误现象：ERROR 1442 (HY000): Can't update table 't_main' in stored function/trigger because it is already used by statement which invoked this stored function/trigger。这是在 AFTER DELETE 里又去查或改同表导致的 MySQL 限制，不是归档逻辑本身的问题。
-
BEFORE DELETE是唯一能稳定读取完整OLD行数据的时机 - 归档表字段顺序不必和源表一致，但类型要兼容（如
datetime别插进varchar） - 如果归档表有自增主键，记得显式插入
NULL或跳过该列，避免冲突
MySQL 中触发器归档性能差得离谱怎么办
单条 DELETE 触发一次归档 INSERT，看起来没问题，但批量删（比如 DELETE FROM t_main WHERE status = 'archived'）会变成 N 次独立 INSERT，I/O 和事务开销陡增。更糟的是，触发器执行期间会持锁，阻塞其他操作。
真实场景下，归档量稍大（>1k 行）就该放弃触发器方案。它适合“偶尔删一两条、必须立刻留痕”的审计类需求，不适合业务级数据迁移。
- 批量归档优先走应用层定时任务 +
INSERT ... SELECT+DELETE分步事务 - 若坚持用触发器，至少给归档表加覆盖索引，加速
INSERT的主键写入 - 不要在触发器里调用存储过程做复杂逻辑——每多一层嵌套，锁等待风险翻倍
PostgreSQL 的 FOR EACH ROW 触发器怎么写归档
PG 的语法更明确：必须声明 FOR EACH ROW，且只能在 BEFORE 或 AFTER 中选其一。BEFORE 可读写 OLD，AFTER 只读，但支持并发安全地写归档表（因为原表已解锁）。
关键差异在于 PG 允许 AFTER 触发器中操作其他表，不报错，所以比 MySQL 更灵活。但别因此掉以轻心——AFTER 里归档失败会导致整个 DELETE 回滚，除非你手动捕获异常并转为异步处理（这已超出触发器能力）。
- PG 示例：
CREATE TRIGGER archive_on_delete BEFORE DELETE ON t_main FOR EACH ROW EXECUTE FUNCTION insert_to_archive() - 函数体里用
INSERT INTO archive_t SELECT OLD.*最简，但注意SELECT *在表结构变更后可能出错 - 如果归档表有额外字段（如
archived_at timestamp），必须显式列出所有目标列，避免隐式匹配失败
触发器归档漏数据或重复归档怎么排查
根本原因就两个：事务隔离没控住，或者触发器被绕过了。比如应用层用 TRUNCATE 删除——它不走触发器；又或者开启了 sql_log_bin=0 跳过 binlog，某些复制环境会连带跳过触发器。
最容易被忽略的是：触发器只响应 DML，不响应 DDL。哪怕你加了 ON DROP TABLE 这种事件（PG 支持，MySQL 不支持），也救不了误删整表的场景。
- 检查是否用了
TRUNCATE：它比DELETE快，但彻底绕过触发器 - 确认用户权限：低权限账号执行
DELETE时，若触发器涉及跨库写入，可能因权限不足静默失败 - 归档表加唯一约束（如
(src_id, deleted_at)），靠数据库拦住重复插入，比代码判断更可靠
归档这事，触发器只是个胶带——临时粘得住，但别指望它扛住高吞吐或结构演进。真要稳，就得接受“删”和“归”是两件事，中间得留空隙、加监控、设兜底。
