不能对历史归档表执行update操作，因其核心语义是“只追加、不可变”，用于保留时点快照以支持审计与回溯；若允许update，将破坏时间线完整性，导致下游报表和合规查询结果错误。
不能直接用 UPDATE 关联历史归档表来“同步主表数据”——历史归档表不是用来被 UPDATE 的，而是用来 INSERT 的。
为什么不能对历史归档表执行 UPDATE 操作
历史归档表的核心语义是“只追加、不可变”。它的存在意义是保留某一时点的快照，用于审计、回溯或合规查询。一旦允许 UPDATE，就破坏了时间线的完整性，比如你把 2023 年归档的订单状态从 'shipped' 改成 'cancelled'，下游报表和法务审计看到的就是错误的历史。
常见误操作包括：
- 写
UPDATE archive_order SET status = (SELECT status FROM order WHERE id = archive_order.order_id)—— 这类语句看似“同步”，实则混淆了主表当前态与历史态 - 在归档脚本里先
DELETE FROM archive_order WHERE ...再INSERT INTO archive_order SELECT ...—— 删除再插入虽可行，但违背归档“可追溯”前提（删掉旧记录，就丢了原始归档时间戳）
正确做法：用 INSERT INTO ... SELECT 构建带时间戳的归档快照
归档动作本质是“把主表中满足条件的一批数据，连同当前归档时间，一次性写入历史表”。关键在于明确归档边界和附加元信息。
典型步骤如下：
- 确保历史表有显式时间字段，如
archived_at DATETIME2 DEFAULT GETDATE()或valid_from DATETIME2 - 归档语句必须带确定的
WHERE条件，例如：WHERE updated_time - 用
INSERT INTO archive_order (id, user_id, amount, status, archived_at) SELECT id, user_id, amount, status, GETDATE() FROM order WHERE ... - 避免在
SELECT中对字段做函数转换（如UPPER(name)），否则可能影响索引使用；若需清洗，提前在主表视图或 CTE 中处理
如何避免归档时覆盖或重复写入
历史表通常不设主键（或仅设非业务主键），但必须防止同一笔数据被多次归档。推荐用组合唯一约束或应用层幂等控制：
- 在历史表加唯一索引：
CREATE UNIQUE INDEX UX_archive_order_id_archived_at ON archive_order (order_id, archived_at)，靠archived_at微秒级精度防重 - 更稳妥的做法是在归档前查重：
SELECT COUNT(*) FROM archive_order WHERE order_id IN (SELECT id FROM order WHERE ...)，为 0 才执行 INSERT - 禁用
INSERT IGNORE或ON DUPLICATE KEY UPDATE—— SQL Server 不支持这些语法；如用 MERGE，请确保WHEN NOT MATCHED THEN INSERT分支逻辑清晰，且MATCHED条件不含时间字段
归档后主表要不要删？删之前必须确认三件事
归档 ≠ 删除。是否 DELETE 主表数据，取决于业务 SLA 和合规要求。执行前务必核验：
- 主表对应数据是否已无任何业务更新可能（例如订单已关单、发票已红冲、合同已履约完毕）
- 所有外键关联表（如订单明细、支付流水、日志表）是否已完成同步归档或持久化备份
- 线上查询是否仍依赖该数据（如某些报表仍按全量时间范围查询，未切到归档表）
真正容易被忽略的是第三点：很多团队归档完就删，结果第二天 BI 报表崩了，才发现前端没改 SQL 的 FROM 表名。归档上线前，必须同步更新所有下游 SQL、视图、ETL 任务里的表引用。
