SQL Server合并复制Msmerge_content表64GB超大数据清理求助

作为常年跟SQL Server合并复制打交道的老DBA，我太懂你刚入职就碰这个“数据炸弹”的崩溃感了——64GB、640亿条的Msmerge_contents，百分百是订阅没设置过期期限，导致历史复制元数据无限堆积出来的锅。简单恢复模式下直接跑DELETE绝对会踩坑：要么事务日志暴涨（别以为简单恢复就不会生成日志，大DELETE的原子性要求还是会写大量日志），要么锁表超时，甚至搞崩整个复制同步。

我给你一套经过实战验证的清理方案，避开这些雷区：

一、先堵根源：给订阅设置过期期限 #

• 先把源头掐了，不然清完数据还会继续疯长。打开复制监视器，找到对应的合并发布，修改发布属性，设置订阅保留期限（比如根据业务需求设30天，也就是超过30天的订阅元数据会被自动清理）。这一步一定要先做，不然白忙活。

二、分批小量删除，避免锁表和日志爆炸 #

直接全量DELETE绝对不可取，得用循环分批删，每次只删一小部分（比如1万条），删完就提交事务释放资源：

-- 配置批量删除的大小，根据你的服务器性能调整，别贪大
DECLARE @BatchSize INT = 10000;
DECLARE @DeletedRows INT = 1;

-- 循环删除直到没有符合条件的记录
WHILE @DeletedRows > 0
BEGIN
    BEGIN TRANSACTION;
    -- 只删除过期的元数据，通过Msmerge_genhistory关联判断gen是否过期
    DELETE TOP (@BatchSize) 
    FROM Msmerge_contents
    WHERE gen IN (
        SELECT gen 
        FROM Msmerge_genhistory 
        WHERE gen_end_time < DATEADD(day, -30, GETDATE()) -- 这里的30天要和你设置的订阅过期期限一致
    );
    
    SET @DeletedRows = @@ROWCOUNT;
    COMMIT TRANSACTION;
    -- 可选：加个短延迟，给服务器留喘气的时间，避免CPU/IO拉满
    WAITFOR DELAY '00:00:01';
END

重点提醒：一定要通过Msmerge_genhistory关联过滤！Msmerge_contents里的gen对应复制生成的历史记录，只有过期的gen对应的内容才是安全可删的，千万别瞎删活跃复制需要的元数据！

三、超大规模表的终极方案：分区切换 #

如果分批删还是太慢（毕竟640亿条，哪怕每次删1万条也要跑很久），可以试试分区切换，这几乎是最快的清理方式：

1. 先给Msmerge_contents按gen字段或者元数据创建时间做分区（如果还没分区的话）。
2. 把存储过期数据的分区直接切换到一个临时空表，然后再删除这个临时表。
   分区切换是元数据级别的操作，几乎不消耗IO和CPU，几分钟就能搞定几十GB的数据，但前提是你得提前规划好分区策略，并且确保要切换的分区里全是可以安全删除的过期数据。

四、清理前后必做的几件事 #

• 备份优先：不管什么情况，清理前一定要做一次完整数据库备份！哪怕是简单恢复模式，万一删错数据还能救回来。
• 避开高峰：哪怕是分批删，还是会产生锁，尽量在业务低峰期执行，避免影响正常业务。
• 重建索引：大删除后Msmerge_contents的索引碎片会非常严重，清理完成后一定要重建或重组索引，不然会拖慢后续的复制同步性能。
• 监控复制状态：清理过程中要盯着复制监视器，确保订阅端同步正常，没有出现中断或报错。

内容的提问来源于stack exchange，提问作者Ahsan Mumtaz Abbasi