BUG的發(fā)現(xiàn)

我們系統(tǒng)中有個(gè)重算日志的頁(yè)面，頁(yè)面主要字段大致有三個(gè)：
重算的開(kāi)始日期、重算的結(jié)束日期、重算的狀態(tài)。
頁(yè)面上是按照重算開(kāi)始日期倒序排列的，很符合常理，因?yàn)檎Ｇ闆r下，人們總是希望看到最近的記錄。

但是該功能做過(guò)一次迭代后端數(shù)據(jù)庫(kù)從mysql變成tidb了，然后看到重算日志頁(yè)面的更新的日期沒(méi)有排在最上面，追查后得知，該功能實(shí)現(xiàn)原理其實(shí)不是按照重算開(kāi)始日期倒序排列的，而是用的id倒序排列。正常情況下，日期越新（離現(xiàn)在越近），id會(huì)越大，id是遞增的。但是這種情況tidb不適用，對(duì)于tidb來(lái)說(shuō)自增主鍵不是全局單調(diào)遞增的。

原理

tidb是分布式的數(shù)據(jù)庫(kù)，為了降低分布式分配自增id的網(wǎng)絡(luò)開(kāi)銷(xiāo)，每個(gè)tidb節(jié)點(diǎn)會(huì)緩存一段不重復(fù)的id段，只有當(dāng)預(yù)分配的id段使用完畢，或者tidb重啟的時(shí)候才會(huì)重新申請(qǐng)新的id端。
舉個(gè)例子，節(jié)點(diǎn)1預(yù)分配的id段為1000-3000，節(jié)點(diǎn)2預(yù)分配的id段為3000-6000，這時(shí)候插入一條數(shù)據(jù)a，通過(guò)節(jié)點(diǎn)2插入，這條數(shù)據(jù)的id在3000-6000范圍內(nèi)，然后隨后又插入一條數(shù)據(jù)b，通過(guò)節(jié)點(diǎn)1插入，這條數(shù)據(jù)的id在1000-3000范圍內(nèi)，于是就出現(xiàn)了數(shù)據(jù)b時(shí)間更新，但是id更小的情況。