数据同步Sql查询慎用时间字段

[yuanrui]

最近开发一个Redis数据同步程序遇到一个奇怪的问题，在同步大量数据时，Redis中存储的数量和数据表中数量不一致。经过一些简单测试Redis Hash类型每秒大概存储1000条数据左右。一次性查询和提交上百万的数据，会造成内存暴涨和同步耗时过长等问题，因此存储大量数据时，需要对数据进行分批次同步处理。具体处理过程，查询待同步的总数据量，设定批次查询总数量，构造Sql进行分页查询，将查询结果序列化为Json后存储到Redis中。 在设计Redis同步程序时，考虑到程序的通用性和后续业务的扩展，需要同步的数据源主要通过配置的方式，来完成数据从Oracle中同步到Redis中。配置主要涉及到：查询字段、表名称、主键字段、修改时间字段等信息。“同步时应该优先同步变化的数据，然后再同步历史的数据，具体操作主要是在分页语句中对修改时间字段进行逆序查询。” 理想很美好，现实很骨感。测试提了一个bug, Db中数据有100w条左右数据，Redis中只有80w条。 也许你已经想到了，在同步的过程中，数据发生了变化。根据修改时间字段排序时，当时间发生变化时，分页条件查询的数据也会发生相应的变化，导致某些部分数据未同步。解决这个问题也很简单，分页查询根据主键字段进行排序，示例如下： 最终查询结果对比： 总结：在同步大量数据时，在需要做分页处理的情况下，尽可能的使用主键字段等数据变化少的字段，避免查询时有所遗漏。同时单页查询数据量需要特殊考虑，分页查询数量过多过少，对性能的也有所影响。