触发器中禁止使用RETURN或CANCEL终止删除，必须通过抛异常（如RAISE EXCEPTION、THROW、SIGNAL）阻断操作；PostgreSQL推荐AFTER DELETE触发器归档后再报错以保障原子性，MySQL因AFTER中抛错不安全，应改用应用层事务控制。
触发器里不能用 RETURN 或 CANCEL 语句
SQL 标准中没有 RETURN、CANCEL 或 ABORT 这类直接中断 DELETE 的语法。触发器本身不阻止原操作，它只是在操作发生前（BEFORE DELETE）或后（AFTER DELETE）执行一段逻辑。想“拦截”DELETE，必须靠主动抛错来阻断，再配合归档动作——但要注意顺序：先归档，再报错，否则归档可能失败就没了。
常见错误是写成：BEFORE DELETE 中插入归档表，然后 RAISE EXCEPTION ——这看似合理，但 PostgreSQL 中 BEFORE 触发器若抛异常，整个事务回滚，归档插入也会被撤销。正确做法是用 AFTER DELETE，并在其中完成归档；如果归档失败，再抛错让 DELETE 最终也失败（保证原子性不丢失数据）。
PostgreSQL 中用 AFTER DELETE + INSERT ... SELECT 实现归档
这是最稳妥的实操路径。前提是归档表结构与原表一致（或字段可映射），且有额外字段记录归档时间、操作人等元信息。
-
AFTER DELETE触发器函数内，用INSERT INTO archive_table SELECT ... FROM OLD把被删行写入归档表 - 归档表需包含时间戳字段，例如
archived_at TIMESTAMPTZ DEFAULT NOW() - 若需记录谁删的，可在应用层传入
current_user或通过pg_backend_pid()关联 session 日志（不推荐依赖后者） - 务必在
INSERT后检查GET DIAGNOSTICS row_count = ROW_COUNT，若为 0 则说明没插进去，应RAISE EXCEPTION 'archive failed'
示例片段（PostgreSQL）：
CREATE OR REPLACE FUNCTION archive_deleted_orders()
RETURNS TRIGGER AS $$
BEGIN
INSERT INTO orders_archive
SELECT *, NOW(), current_user FROM OLD;
IF NOT FOUND THEN
RAISE EXCEPTION 'failed to archive order %', OLD.order_id;
END IF;
RETURN NULL;
END;
$$ LANGUAGE plpgsql;MySQL 不支持 AFTER ROW 级触发器中的 NEW/OLD 引用？
MySQL 5.7+ 是支持的，但有个关键限制：AFTER DELETE 触发器里只能访问 OLD，不能用 NEW（因为没新行）；而 BEFORE DELETE 虽能访问 OLD，但如前所述，无法安全归档——因为一旦后续语句出错，整个事务回滚，归档就白做了。
所以 MySQL 实际可行方案只有两个：
- 接受风险，用
BEFORE DELETE归档 + 不抛错（即允许 DELETE 继续，归档失败也不拦）——不推荐 - 改用应用层控制：禁止直接
DELETE FROM orders，统一走存储过程，过程里先INSERT INTO archive ... SELECT ...，再DELETE，用事务包住两者
MySQL 触发器里没有 RAISE，要用 SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '...' 抛自定义错误，但仅在 BEFORE 中有效；AFTER 中抛错会导致未定义行为（官方文档明确标注“不建议”）。
归档表主键和索引容易被忽略
归档表不是垃圾桶，长期运行后查询会变慢。上线前必须确认：
- 归档表要有独立主键（比如加
archive_id SERIAL PRIMARY KEY），别直接复用原表主键——否则未来恢复时可能冲突 - 至少在
archived_at和原业务主键（如order_id）上建复合索引：CREATE INDEX idx_archive_order_time ON orders_archive(order_id, archived_at) - 定期分区（按月/按年）比单表更可控，PostgreSQL 支持
PARTITION BY RANGE (archived_at)，MySQL 8.0+ 也支持类似语法
没加索引的归档表，半年后查某条订单是否被删过，SELECT * FROM orders_archive WHERE order_id = 12345 就是全表扫描——这时候才想起加索引，锁表时间可能长达数小时。
