SQL Server 删除触发器必须用AFTER而非INSTEAD OF，以可靠访问deleted表；MySQL无deleted表，需用BEFORE DELETE配合变量逐行保存；两者均需注意字段对齐、事务一致性及性能优化。
DELETE 触发器必须用 AFTER 而不是 INSTEAD OF
触发器在删除前（INSTEAD OF）无法直接获取被删行的完整快照，尤其在多行 DELETE 时容易漏数据；而 AFTER DELETE 触发器能稳定访问 deleted 临时表，这是 SQL Server 唯一可靠的删除后捕获机制。MySQL 不支持 deleted 表，需改用 BEFORE DELETE + 显式 INSERT —— 这点常被跨数据库迁移的人忽略。
SQL Server 中正确引用 deleted 表并插入历史表
deleted 是只读虚拟表，结构与原表一致，每行对应一条被删记录。写入历史表时必须严格对齐字段顺序和类型，不能用 SELECT * FROM deleted 直接插，除非历史表字段完全一致且顺序相同。
常见错误现象：INSERT INTO history_table SELECT * FROM deleted 报错“列名或序号不匹配”，或插入 NULL 到非空字段。
实操建议：
- 显式列出字段：
INSERT INTO order_history (id, customer_id, amount, deleted_at) SELECT id, customer_id, amount, GETDATE() FROM deleted - 确保
order_history的id是普通列而非IDENTITY（否则会报错），或在INSERT前加SET IDENTITY_INSERT order_history ON - 如果原表有计算列、默认约束、触发器递归风险，
deleted表里这些值已固化，无需额外处理
MySQL 实现等效逻辑要绕过 deleted 表缺失问题
MySQL 没有 deleted 表，只能在 BEFORE DELETE 触发器中逐行保存。这意味着不能批量插入，且必须用局部变量暂存每行数据。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
实操建议：
- 用
DECLARE定义变量，逐字段赋值：SET @old_id = OLD.id; SET @old_amount = OLD.amount; - 紧接着
INSERT INTO order_history VALUES (@old_id, @old_amount, NOW()); - 不能在
BEFORE DELETE里修改OLD的值（只读），也不允许对同一张表做 DML（会报错Can't update table 'orders' in stored function/trigger），所以历史表必须是另一张独立表 - 注意字符集和时区：若主库用
utf8mb4而历史表建为utf8，可能丢表情符号；NOW()取的是系统时间，不是事务开始时间
触发器性能和事务一致性要点
触发器运行在原 DELETE 事务内，历史表写入失败会导致整个删除回滚 —— 这既是保障，也是风险点。比如历史表磁盘满、字段长度超限、外键冲突，都会让业务删除失败。
容易踩的坑：
- 没加索引的历史表在高频删除下写入变慢，拖累主表操作；建议对
deleted_at或source_id建索引 - 误把
AFTER DELETE写成AFTER UPDATE，结果删数据不备份 - 触发器里调用存储过程或远程服务，导致事务持锁时间过长，引发阻塞
- 未考虑分区表场景：若原表按月分区，历史表最好也按时间分区，否则几年后单表太大难查
最常被忽略的是触发器嵌套：一个 DELETE 触发另一个表的 UPDATE，又触发第三个表的 INSERT，层层叠加后逻辑失控。上线前务必用 SELECT * FROM sys.triggers（SQL Server）或 SHOW TRIGGERS（MySQL）确认层级和状态。
