同步数据，我们比较关心的是如何尽可能地减少每次的同步数据量，以提高同步效率，降低对网络带宽的消耗。对于大批量的数据同步，这一点尤其需要考虑。如果解决这个问题呢，我认为关键点在于获取差异数据，也就是说，我们只同步变化了的数据，没有变化的，就不用同步。
就此，我总结了5种方法，各种方法各有优劣，下面一一道来。
1．SQLServer本身的复制服务
本身支持多种数据同步方式，功能很强大，但是使用上会比较复杂，而且如果在同步过程中，需要对差异数据做二次处理，似乎无路可走。
2．Trigger
可以实时获取差异数据， Trigger使用较为容易，不需要改变原表的结构，可以只监视部分的栏位变更，以获取你需要的变化数据，并对数据做二次处理。Trigger需要你对源表的维护状况比较了解，否则可能产生一些意想不到的影响。
3．日期栏位(时间戳)
简单而言，在设计表的时候，添加两个日期栏位，CreatedOn, ChangedOn, 分别记录数据产生时间和变更时间。同步程序可以根据两个栏位来获取差异的数据。
这种方法可以保证随时获取某个时间段内新增(变化)的数据，同时对于追踪问题也大有裨益。但是缺陷也不少，其一是这两个栏位完全由开发人员控制，切实保证这两个栏位每次都得到正确的维护比较困难，其二是不容易确定你下一次取差异数据的基准时间。
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)，所以要监控这些列变化，这种方法就无能为力了。
俗话说得好，到什么山上唱什么歌，上面列举的方法只是在遇到此类问题的时候，能够给我们更多的选择，究竟如何取舍，还是具体问题具体分析了！
