MySQL不支持AFTER DELETE触发器，仅支持BEFORE DELETE；SQL Server和PostgreSQL支持AFTER DELETE，但需显式列名、禁用事务控制、注意返回值与权限，且批量删除时须用集合操作而非游标。
After Delete触发器怎么写才不会丢数据
直接上结论：SQL Server、PostgreSQL 支持 AFTER DELETE 触发器，MySQL 仅支持 BEFORE DELETE（5.7+ 不支持 AFTER），想“删完再存历史”，MySQL 必须改用存储过程或应用层双写。别硬套语法，先看数据库类型。
常见错误是把 INSERT INTO history_table SELECT * 写在触发器里，但没显式列出字段——一旦源表加字段或顺序变，触发器就报错或插错列。必须用完整字段列表。
-
INSERT INTO order_history (id, user_id, amount, status, deleted_at) SELECT id, user_id, amount, status, GETDATE() FROM deleted;（SQL Server） - PostgreSQL 用
OLD TABLE替代deleted，且必须加FOR EACH ROW - 触发器里禁止调用事务控制语句（如
COMMIT），否则报错；删除本身已在一个事务中，历史表插入自动同事务回滚
DELETE后同步失败，为什么历史表没数据
最常被忽略的是触发器未启用或权限不足。SELECT is_disabled FROM sys.triggers WHERE name = 'tr_order_after_delete'; 查是否禁用；sysadmin 或 db_owner 才能创建/启用触发器，普通 db_datawriter 权限不够。
另一个坑：触发器里用了 @@ROWCOUNT 或 RAISERROR 后没 RETURN，导致后续逻辑继续执行，甚至误插空行。
- 批量删除（如
DELETE FROM orders WHERE status = 'cancelled'）会触发一次触发器，但deleted表含多行——确保INSERT ... SELECT是集合操作，别写成游标循环 - 如果历史表有自增主键，而源表没有对应字段，
SELECT *会因列数不匹配直接报错 - PostgreSQL 中触发器函数返回值必须是
TRIGGER类型，且最后一行得是RETURN OLD;或RETURN NULL;（AFTER触发器通常用RETURN NULL）
性能影响有多大？大表删数据卡顿是不是触发器惹的祸
是。每次 DELETE 都要额外执行一次 INSERT + 索引维护，I/O 和锁时间翻倍。10万行删除可能从200ms拖到1.5秒以上。
真实场景中，订单表日删千条还行；但日志类表每秒删上万条，AFTER DELETE 触发器会成为瓶颈。这时应考虑异步方案：删前把ID写入队列表，由后台Job异步搬数据。
- 避免在触发器里做远程调用、文件写入、HTTP请求——超时或失败会导致主删除事务失败
- 历史表建议关闭非必要索引（如全文索引），只保留按
deleted_at或source_id的查询索引 - SQL Server 可用
NOT FOR REPLICATION选项，让复制环境跳过触发器，防止双写冲突
MySQL用户怎么办：没有AFTER DELETE，还能不能保历史
不能靠触发器原生实现。可行路径只有两条：应用层双写 或 用事件调度+临时表模拟。
推荐双写：应用代码中用事务包住 DELETE FROM orders WHERE id = ? 和 INSERT INTO orders_history ...。虽然多一次SQL，但可控、可重试、可打日志。
- 若坚持用MySQL触发器，只能
BEFORE DELETE把数据INSERT进历史表，但此时原记录还在，需加标记字段（如is_deleted = 1）代替物理删除 - 用
EVENT定时扫描标记表，每分钟把is_deleted = 1的行搬走并真删——延迟不可控，不适合审计强要求场景 - Percona Toolkit 的
pt-archiver工具可安全归档+删除，适合定期清理大表，但不是实时同步
真正难的不是语法，是决定“历史”要不要强一致性。业务能接受秒级延迟，就别死磕触发器；要求删即存，就得接受应用层多一跳和事务复杂度。
