SQL Server事务复制：发布端清理数据不影响订阅端的解决方案咨询

这是事务复制里非常典型的场景——发布端需要定期清理旧数据，但订阅端要保留全量历史。我给你几个经过实践验证的解决方案，你可以根据自己的业务规模和现有架构来选：

方案1：分区切换+归档表（推荐大数据量场景） #

这是性能最优的方案，因为直接DELETE大量数据会产生巨量事务日志，拖慢复制链路，而分区切换是元数据操作，几乎不产生日志，还能完美隔离订阅端的数据。

具体步骤：

• 先把发布端的业务表按日期做分区（比如按天创建分区），分区函数用RANGE RIGHT或者RANGE LEFT根据你的日期字段来定义
• 创建一个和业务表结构完全一致的归档表，注意这个归档表不要加入到发布中
• 定期执行分区切换：把超过3天的旧数据所在的分区，从业务表切换到归档表（用ALTER TABLE ... SWITCH PARTITION ... TO ...命令）
• 最后可以从归档表中删除数据（或者保留归档表做冷备，看你的需求）

为什么这个方案不会影响订阅端？因为归档表不在发布范围内，分区切换操作只会修改发布端的元数据，不会被复制代理捕获，订阅端的业务表会一直保留所有历史分区的数据。

示例代码（假设日期字段是CreateTime，分区按天划分）：

-- 切换3天前的分区到归档表
ALTER TABLE dbo.BusinessTable
SWITCH PARTITION $PARTITION.PF_BusinessTable_Date(GETDATE()-3)
TO dbo.Archive_BusinessTable;

-- 可选：删除归档表中的数据
DELETE FROM dbo.Archive_BusinessTable;

方案2：自定义存储过程+复制架构仅同步（适合小数据量/现有逻辑复用） #

如果你的数据量不大，或者已经有成熟的删除存储过程，可以用这个方法，让发布端执行删除但不复制到订阅端：

具体步骤：

• 在发布端创建专门的清理存储过程，比如dbo.CleanupOldData，里面写好删除3天前数据的逻辑
• 在配置发布文章的时候，把这个存储过程以仅同步架构的方式发布：

  EXEC sp_addarticle
    @publication = '你的发布名称',
    @article = 'CleanupOldData',
    @source_object = 'dbo.CleanupOldData',
    @type = 'proc schema only',
    @schema_option = 0x0000000000000001;
  

• 之后在发布端定期执行这个存储过程清理数据，订阅端虽然会有这个存储过程，但复制代理不会把存储过程的执行命令同步过去，所以订阅端的数据不会被删除

注意：如果你的删除逻辑是直接写在Job里的DELETE语句，而不是存储过程，也可以把这段DELETE逻辑封装到存储过程里再用这个方法，这样更规范。

方案3：会话判断跳过复制（灵活但需注意细节） #

你也可以在删除逻辑里加入会话判断，让复制代理执行的时候跳过删除，但这个方法更适合特殊场景：

在你的删除存储过程里，先检查当前会话是不是复制代理的会话，如果是就直接退出，否则执行删除：

CREATE PROCEDURE dbo.CleanupOldData
AS
BEGIN
  -- 判断当前会话是否是复制代理会话
  IF EXISTS (
    SELECT 1 FROM sys.dm_exec_sessions
    WHERE session_id = @@SPID AND is_replication_agent = 1
  )
  BEGIN
    RETURN;
  END

  -- 执行删除逻辑
  DELETE FROM dbo.BusinessTable
  WHERE CreateTime < GETDATE()-3;
END

不过这个方法要注意：如果你的复制代理用的是和清理Job同一个会话（可能性很低，但要避免），可能会导致发布端的数据没被清理，所以最好还是用前两个方案。

避坑提醒 #

• 无论选哪个方案，都一定要先在测试环境验证，确保不会影响正常的业务复制和数据一致性
• 如果用分区切换，订阅端的表不需要做分区，因为订阅端要保留全量数据
• 大数据量场景下，坚决不要用直接DELETE的方式，不仅会拖慢复制，还可能导致发布端日志暴涨，影响OLTP性能

内容的提问来源于stack exchange，提问作者Tanvir Arafat