SQL Server复制功能用得好，避开那些让人头疼的Bug小技巧分享

综合自多位资深DBA的实践经验分享及技术社区常见问题汇总）

SQL Server的复制功能是个强大的工具，用好了能轻松搞定数据同步，但要是没摸清门道，各种稀奇古怪的Bug能让你加班到天亮，下面这些可不是书本上的理论，都是老司机们踩过坑后总结出来的实用技巧。

开局最重要：规划与设计阶段就要避坑

很多问题其实在第一步就埋下了种子,别一上来就急着建发布订阅，先花点时间想清楚。

1. 选择合适的复制类型：这是源头。（来源：多位DBA强调）

   • 快照复制：适合数据量不大、更新不频繁，且能接受一段时间数据延迟的场景，比如初始化数据仓库、静态参数表同步，千万别用它来同步频繁交易的表，否则网络和服务器压力巨大。
   • 事务复制：最常用，适合需要近乎实时同步、增量数据量大的场景，但要注意，如果表没有主键，事务复制根本用不了，这是硬性规定。
   • 合并复制：适合移动办公、分支机构等网络不稳定的环境，允许双方独立更新再合并，但冲突处理是最大的坑，必须在设计阶段就定义好清晰的冲突解决策略（比如优先采用哪个站点的数据），否则等冲突发生了再去收拾烂摊子就麻烦了。

2. 给表一个健壮的主键：（来源：SQL Server官方文档及社区故障排查案例） 事务复制强烈要求每个表都必须有主键，但这里有个小细节：主键最好选择稳定的、不随时间变化的列（比如自增ID、GUID），避免使用可能被更新的字段（如员工编号，理论上不该变但业务可能强制要求变）作为主键，否则在复制过程中可能会引发意想不到的错误。

配置过程中的“魔鬼细节”

配置时手一抖,后期排查累成狗。

1. 小心处理“标识列”：（来源：大量复制中断的求助帖总结） 如果表里有自增标识列（IDENTITY），在订阅端，这个列的属性需要特殊设置，发布端的标识列是“种子”和“递增量”，比如从1开始，每次加1，订阅端如果也是同样的设置，两边同时插入数据就必然导致主键冲突。 正确的做法是：在配置订阅时，将订阅端的标识范围设置为与发布端不重叠，发布端从1开始，每次增1；订阅端可以从10万开始，每次增1，或者更稳妥的方法是，只在发布端允许插入，订阅端该列设为只读。

2. 初始化快照的路径问题：（来源：新手DBA常见失误） 默认情况下，快照文件会生成在发布服务器的一个本地文件夹里，如果订阅服务器和发布服务器不在同一台机器上，订阅代理会找不到这个快照文件，导致初始化失败。 解决办法是：要么使用网络共享路径，确保发布和订阅服务器都能访问这个共享文件夹（并设置好正确的读写权限）；要么使用FTP方式来传输快照，千万别忽略这个权限设置，账户权限问题是快照初始化失败的头号元凶。

3. 别忽略“非聚集索引”的选项：（来源：性能优化经验谈） 在创建发布时，有一个选项是“复制索引”，默认可能只复制主键/唯一约束对应的索引，而非聚集索引不复制，如果你的查询性能高度依赖订阅端的某些非聚集索引，一定要在文章属性里勾选上“复制非聚集索引”，否则你会发现订阅端表是同步了，但查询慢得吓人，还得手动去补建索引。

运行维护中的监控与排雷

复制链路建好不是一劳永逸,需要日常照看。

1. 盯紧复制监控器：（来源：DBA日常工作守则） SQL Server自带的复制监控器是你的最佳战友，不要等业务部门报告数据不对了才去看，要经常检查三个关键指标：

   • 延迟：数据从发布到订阅花了多长时间？如果延迟持续增长，说明系统可能不堪重负或有阻塞。
   • 性能：日志读取器代理、分发代理的性能计数器，看看是否有命令积压。
   • 错误信息：一旦出现错误，监控器里会有详细记录，这是排查问题的第一手资料。

2. 处理“大事务”要格外小心：（来源：生产环境事故报告） 如果一个事务一次性更新或删除了几十万甚至上百万行数据，这个事务在复制时会被当作一个整体单位，这可能会导致：

   • 分发数据库暴涨：这个巨大的事务会长时间占用分发数据库的空间和日志，可能把磁盘撑满。
   • 订阅端延迟剧增：订阅端需要一次性应用这个庞然大物，可能会阻塞其他小事务，甚至超时失败。 对策是：在业务设计上，尽量避免这种超大事务，将其拆分成多个小批量操作（比如每次处理5000行）。

3. 定期清理分发数据库：（来源：SQL Server维护计划建议） 分发数据库就像个中转站，事务被传递给所有订阅者后，这些历史记录理论上就可以清掉了，如果清理作业（ cleanup job）失败或没运行，分发数据库会无限增大，最终拖慢整个复制速度甚至使磁盘爆满，确保分发清理作业和代理历史记录清理作业正常运行。

4. schema变更（表结构修改）的规范操作：（来源：血泪教训） 直接在发布表上执行ALTER TABLE添加列，复制能自动同步过去吗？有时可以，但非常不推荐！特别是删除列、更改数据类型等危险操作，很容易导致复制失败。 最稳妥的方法是：先停止复制代理，然后在发布端和订阅端手动、按相同顺序执行schema变更脚本，确保两边结构一致后，再重新启动代理，虽然麻烦，但能避免90%因结构变更导致的复制中断。

心态与流程

1. 搭建测试环境演练：（来源：所有资深人士的共识） 任何复制配置的变更（包括上面说的schema变更）、新发布的添加，都必须在测试环境充分验证后再上生产，复制涉及的组件多，链路复杂，想当然的操作必然出问题。

2. 文档化：（来源：团队协作必备） 把你规划的复制类型、各个服务器的角色、处理过的特殊问题（比如某个表需要自定义筛选器）都记录下来，否则时间一长，你自己都会忘记，更别说交接给同事了。

用好SQL Server复制的关键，不在于多么高深的技术，而在于细致的规划、谨慎的操作和持续的监控，把这些小技巧变成习惯，就能让复制功能真正成为你的得力助手，而不是噩梦的来源。