触发器中直接用 INSERT INTO Archive SELECT * FROM deleted 会出错，因 Archive 表字段顺序、类型、空值性或新增审计字段（如 ArchiveTime）常与原表不匹配；必须显式指定列名并处理类型转换、标识列、NULL 约束及事务一致性。
触发器里直接用 INSERT INTO Archive SELECT * 会出错
SQL Server 的 deleted 表是临时结果集，结构和原表一致，但不能直接用 SELECT * 插入到 Archive 表——除非 Archive 表字段顺序、数量、类型、空值性完全匹配原表，且没有计算列、默认约束或标识列干扰。更常见的是 Archive 表多了 ArchiveTime、Operation 等审计字段，此时 SELECT * 必报错：Column name or number of supplied values does not match table definition。
实操建议：
- 显式列出所有目标字段，包括新增的
ArchiveTime（用GETDATE()）、Operation（设为'DELETE'） - 确保
deleted中字段名与 Archive 表对应列一一映射，尤其注意时间字段是否允许 NULL、是否需要CONVERT类型适配 - 如果 Archive 表有标识列（
IDENTITY），插入时必须SET IDENTITY_INSERT Archive ON，且该语句不能在触发器内执行（权限和作用域限制），应提前关闭标识或改用序列
DELETE 触发器必须用 AFTER DELETE，不能用 INSTEAD OF
INSTEAD OF DELETE 会替代原删除操作，导致数据没真删掉，只进了 Archive——这违背“归档+清理”的原始意图。而 AFTER DELETE 在原行已从主表物理移除后触发，deleted 表内容稳定可靠，适合归档。
实操建议：
- 创建触发器时明确写
CREATE TRIGGER ... ON [Table] AFTER DELETE AS - 避免在触发器中再对原表做
UPDATE或DELETE，可能引发嵌套触发器死锁或性能雪崩 - 若需记录操作人，不要依赖
SYSTEM_USER（可能是代理账号），优先从应用层传入@Operator参数——但触发器无法接收参数，得改用上下文信息（如SESSION_CONTEXT()配合应用端先sp_set_session_context）
大批量 DELETE 会拖慢触发器性能，必须加索引和批处理控制
一次删 10 万行，触发器就得把 10 万行全塞进 deleted 表再逐条 INSERT 到 Archive——没索引的话，Archive 表写入会变成磁盘 I/O 瓶颈，还可能阻塞主表后续操作。
实操建议：
- Archive 表至少在
ArchiveTime和业务主键（如OrderId）上建非聚集索引，避免堆表全表扫描 - 禁止在触发器里写循环（
WHILE+FETCH），SQL Server 会自动批量处理deleted表；只需一条INSERT INTO Archive (...) SELECT ..., GETDATE(), 'DELETE' FROM deleted - 若业务允许，把大删拆成小批（如每次 5000 行），用应用层循环调用，比单次触发器扛 10 万行更稳
Archive 表字段类型不兼容时，deleted 中的 datetime2 写不进 datetime
主表用 datetime2(7)，Archive 表却用旧版 datetime（精度仅 3.33ms，范围 1753–9999），直接插入会报错：Cannot convert datetime2 to datetime。类似问题还有 varchar(max) → varchar(200) 截断、NULL 列往 NOT NULL 列插等。
实操建议：
- 用
TRY_CONVERT包裹高危字段，如TRY_CONVERT(datetime, deleted.CreatedAt)，失败则返回 NULL，避免整个 INSERT 失败 - 对长度敏感字段加
LEFT(deleted.Description, 200)显式截断，并加注释说明归档有损 - 归档前用
IF EXISTS (SELECT 1 FROM deleted WHERE CreatedAt > '9999-12-31')做兜底校验，提前报错而非静默失败
最易被忽略的是事务边界：触发器和原 DELETE 共享同一事务，Archive 写失败会导致主表删除回滚。所以 Archive 表的可用性、磁盘空间、索引健康度，实际决定了线上主表能否成功删数据。
