最近在琢磨异构数据库数据校验的事情，想来想去觉得都不是易事，我想出了一个方案，但最终因为工作量、时间等原因，项目决定不再进行数据校验，在这里分享一下,抛砖引玉，希望得到同仁们的一些更好的方案。

1、 为什么要进行数据校验？

首先要回答这个问题：“为什么要进行异构数据库的数据校验呢？”本博的前两篇文章探讨了进行异构数据库同步的方案，但是不论使用何种方式进行同步，都可能因为各种原因导致两边数据库的不同步，例如一方的 SQL语句执行成功，而另一方转换成新的 SQL语句后执行失败，而没有得到实时处理，或者同步程序存在 bug等原因。

进行数据校验的原因是为了保证两边数据库的数据一致性和完整性。

数据不一致可能导致的结果：

（ 1 ）使得用户进行了某个设置，但未见生效；

（ 2 ）用户已经删除了某设置，但仍然继续生效；

（ 3 ）某个用户在一方平台已经注销或到期，而在另一平台仍然可以使用等等。

贴几段关于数据一致性和数据完整性的代码：

数据一致性通常指关联数据之间的 逻辑 关系是否正确和完整。而 数据存储 的一致性模型则可以认为是 存储系统 和数据使用者之间的一种约定。如果使用者遵循这种约定，则可以得到系统所承诺的访问结果。

数据库 完整性（ Database Integrity）是指数据库中数据的正确性和 相容性 。数据库完整性由各种各样的 完整性约束 来保证，因此可以说数据库完整性设计就是数据库完整性约束的设计。数据完整性包括：实体完整性、域完整性、 参照完整性 和用户定义完整性。可以使用主键、 check约束 和 外键 等来实现。

为了保证数据库的一致性和完整性，设计人员往往会设计过多的表间关联，尽可能的降低数据的冗余。表间关联是一种强制性措施，建立后，对父表和子表的插入、更新、删除操作均要占用系统的开销。

如果数据冗余低，数据的完整性容易得到保证，但增加了表间连接查询的操作，为了提高系统的响应时间，合理的数据冗余也是必要的。使用规则和约束来防止系统操作人员误输入造成数据的错误是设计人员的另一种常用手段，但是，不必要的规则和约束也会占用系统的不必要开销，需要注意的是，约束对数据的有效性验证要比规则快。所有这些，设计人员在设计阶段应根据系统操作的类型、频度加以均衡考虑。

2、 哪些是需要关心的表和字段？

异构数据库的双方需要确定哪些是需要进行数据校验的表？需要关心的字段是哪些？哪一些字段不会影响到业务可以不去关心？毕竟进行数据校验是一个耗时耗力的活。

3、 采用何种数据校验方案

我感觉思维受限，暂时只想到这个个方案：

（ 1 ）关键表的总量比较。

（ 2 ）用户信息的抽样校验：因为主要关心跟用户有关的信息，因此对用户信息进行抽样检验。随机抽取部分用户（例如： 10000 个用户）对其各项信息进行比对，两边的数据按照一样的 XML Schema 生成，可使用各种方式进行比对（例如 Shell 进行文件比对）。