BUG的发现
我们系统中有个重算日志的页面，页面主要字段大致有三个：
重算的开始日期、重算的结束日期、重算的状态。
页面上是按照重算开始日期倒序排列的，很符合常理，因为正常情况下，人们总是希望看到最近的记录。
但是该功能做过一次迭代后端数据库从mysql变成tidb了，然后看到重算日志页面的更新的日期没有排在最上面，追查后得知，该功能实现原理其实不是按照重算开始日期倒序排列的，而是用的id倒序排列。正常情况下，日期越新（离现在越近），id会越大，id是递增的。但是这种情况tidb不适用，对于tidb来说自增主键不是全局单调递增的。
原理
tidb是分布式的数据库，为了降低分布式分配自增id的网络开销，每个tidb节点会缓存一段不重复的id段，只有当预分配的id段使用完毕，或者tidb重启的时候才会重新申请新的id端。
举个例子，节点1预分配的id段为1000-3000，节点2预分配的id段为3000-6000，这时候插入一条数据a，通过节点2插入，这条数据的id在3000-6000范围内，然后随后又插入一条数据b，通过节点1插入，这条数据的id在1000-3000范围内，于是就出现了数据b时间更新，但是id更小的情况。
