MySQL數據庫如何優化(huà)主從延時(shí)

MySQL數據庫是APP開發常用(yòng)的(de)數據，由于其體積小、速度快(kuài)、總體擁有成本低，尤其是開放源碼這(zhè)一特點，一般中小型網站或中小型APP的(de)開發都選擇 MySQL 作爲數據庫。

MySQL主從複制，讀寫分(fēn)離是互聯網常見的(de)數據庫架構，該架構最令人(rén)诟病的(de)地方就是，在數據量較大(dà)并發量較大(dà)的(de)場(chǎng)景下(xià)，主從延時(shí)會比較嚴重。

爲什(shén)麽MySQL數據庫主從延時(shí)這(zhè)麽大(dà)呢(ne)？因爲MySQL使用(yòng)單線程重放RelayLog。所以，如何縮短重放時(shí)間，就是優化(huà)主從延時(shí)的(de)關鍵點。一般我們會采用(yòng)多(duō)線程并行重放RelayLog來(lái)縮短時(shí)間。需要考慮如何分(fēn)割RelayLog，才能夠讓多(duō)個(gè)數據庫實例，多(duō)個(gè)線程并行重放RelayLog，不會出現不一緻。

相同庫上的(de)寫操作，用(yòng)相同的(de)線程來(lái)重放RelayLog；不同庫上的(de)寫操作，可(kě)以并發用(yòng)多(duō)個(gè)線程并發來(lái)重放RelayLog。設計一個(gè)哈希算(suàn)法，hash(db-name) % thread-num，庫名hash之後再模上線程數，就能很輕易做(zuò)到，同一個(gè)庫上的(de)寫操作，被同一個(gè)重放線程串行執行。
 

但是有些公司對(duì)MySQL的(de)使用(yòng)是“單庫多(duō)表”，如果是這(zhè)樣的(de)話(huà)，仍然隻有一個(gè)庫，還(hái)是不能提高(gāo)RelayLog的(de)重放速度。
 

那麽，“單庫多(duō)表”的(de)場(chǎng)景，多(duō)線程并行重放RelayLog還(hái)能怎麽優化(huà)呢(ne)？
即使隻有一個(gè)庫，事務在主庫上也(yě)是并發執行的(de)，既然在主庫上可(kě)以并行執行，在從庫上也(yě)應該能夠并行執行。将主庫上同時(shí)并行執行的(de)事務，分(fēn)爲一組，編一個(gè)号，這(zhè)些事務在從庫上的(de)回放可(kě)以并行執行（事務在主庫上的(de)執行都進入到prepare階段，說明(míng)事務之間沒有沖突，否則就不可(kě)能提交），沒錯，MySQL正是這(zhè)麽做(zuò)的(de)。