MySQL數(shù)據(jù)庫如何優(yōu)化主從延時

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

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

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

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

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

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