说到同步数据，大最为较关心的就是如何尽可能地减少每次的同步数据量，以此来提高同步效率，降低对网络带宽的消耗。针对大批量的数据同步，这一点是必须注意的。解决这个问题的关键点在于获取差异数据，这也就是说，我们仅仅同步变化了的数据，至于没有变化的，就不再同步。下文中，我们将介绍减少每次同步数据量的6个方法：
1．日期栏位(时间戳)
一般情况下，在设计表的时候，添加两个日期栏位，CreatedOn, ChangedOn, 分别记录数据产生时间和变更时间。同步程序可以根据两个栏位来获取差异的数据。
2．Trigger
它可以实时获取差异数据， Trigger使用较为容易，不需要改变原表的结构，可以只监视部分的栏位变更，以获取你需要的变化数据，并对数据做二次处理。Trigger需要你对源表的维护状况比较了解，否则可能产生一些意想不到的影响。
3．SQLServer本身的复制服务
本身支持多种数据同步方式，功能很强大，但是使用上会比较复杂，而且如果在同步过程中，需要对差异数据做二次处理，似乎无路可走。
这种方法可以保证随时获取某个时间段内新增(变化)的数据，同时对于追踪问题也大有裨益。但是缺陷也不少，其一是这两个栏位完全由开发人员控制，切实保证这两个栏位每次都得到正确的维护比较困难，其二是不容易确定你下一次取差异数据的基准时间。
4．timestamp栏位
timestamp可以理解为行的版本号，每次插入或更新包含 timestamp 列的行时，timestamp 列中的值均会更新。利用这一特性，建立一个包含源表ID和timestamp值的基准表，就可以找到哪些数据发生变化了，每次同步成功后，再更新该基准表。
5．监控并记录基于某数据对象的所有DML语句
这种方法，我没有具体尝试过，但是一个很不错的思路，如果网络状况糟糕，而且对数据实时性要求不高，可以采用。具体做法是每天定时获取你需要同步表的所有update, delete语句，然后定点打包发送到另外一台服务器执行。
6．使用BINARY_CHECKSUM
这个是我认为最简单的方法。BINARY_CHECKSUM是SQLServer内置的一个聚合函数，它可以针对一行，或者某些列计算出一个值，如果它计算的那些列中的任何一个值发生变化，那么那个计算值就会发生变化。这样我只要建立一个包含源表ID和最初计算值的基准表，就可以找到哪些数据发生变化了，每次同步成功后，再更新该基准表。与方法4不同的是，BINARY_CHECKSUM可以只监视部分变化的栏位，这一点又类似于Trigger了。
使用BINARY_CHECKSUM有些限制，因为它在计算中会忽略具有不可比数据类型的列(不可比数据类型是 text、ntext、image、cursor 以及基本类型为前4个数据类型之一的 sql_variant)，所以如果要监控这些列变化，这种方法是不起作用的。
