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

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

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

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

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

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