MySQL數據庫是APP開發(fā)常用的數據，由于其體積小、速度快、總體擁有成本低，尤其是開放源碼這一特點，一般中小型網站或中小型APP的開發(fā)都選擇 MySQL 作為數據庫。

MySQL主從復制，讀寫分離是互聯(lián)網常見的數據庫架構，該架構最令人詬病的地方就是，在數據量較大并發(fā)量較大的場景下，主從延時會比較嚴重。

為什么MySQL數據庫主從延時這么大呢？因為MySQL使用單線程重放RelayLog。所以，如何縮短重放時間，就是優(yōu)化主從延時的關鍵點。一般我們會采用多線程并行重放RelayLog來縮短時間。需要考慮如何分割RelayLog，才能夠讓多個數據庫實例，多個線程并行重放RelayLog，不會出現不一致。

相同庫上的寫操作，用相同的線程來重放RelayLog；不同庫上的寫操作，可以并發(fā)用多個線程并發(fā)來重放RelayLog。設計一個哈希算法，hash(db-name) % thread-num，庫名hash之后再模上線程數，就能很輕易做到，同一個庫上的寫操作，被同一個重放線程串行執(zhí)行。
 

但是有些公司對MySQL的使用是“單庫多表”，如果是這樣的話，仍然只有一個庫，還是不能提高RelayLog的重放速度。
 

那么，“單庫多表”的場景，多線程并行重放RelayLog還能怎么優(yōu)化呢？
即使只有一個庫，事務在主庫上也是并發(fā)執(zhí)行的，既然在主庫上可以并行執(zhí)行，在從庫上也應該能夠并行執(zhí)行。將主庫上同時并行執(zhí)行的事務，分為一組，編一個號，這些事務在從庫上的回放可以并行執(zhí)行（事務在主庫上的執(zhí)行都進入到prepare階段，說明事務之間沒有沖突，否則就不可能提交），沒錯，MySQL正是這么做的。