誠然，MySQL 5.6版本也支持所謂的并行復制，但是其并行只是基于schema的，也就是基于庫的。如果用戶的MySQL數據庫實例中存在多個schema，對于從機復制的速度的確可以有比較大的幫助。MySQL 5.6并行復制的架構如下所示： [](http://www.innomysql.net/wp-content/uploads/2015/05/MySQL_Replication_Architecture.png) 在上圖的紅色框框部分就是實現并行復制的關鍵所在。在MySQL 5.6版本之前，Slave服務器上有兩個線程I/O線程和SQL線程。I/O線程負責接收二進制日志（更準確的說是二進制日志的event），SQL線程進行回放二進制日志。如果在MySQL 5.6版本開啟并行復制功能，那么SQL線程就變為了coordinator線程，coordinator線程主要負責以前兩部分的內容： * 若判斷可以并行執行，那么選擇worker線程執行事務的二進制日志 * 若判斷不可以并行執行，如該操作是DDL，亦或者是事務跨schema操作，則等待所有的worker線程執行完成之后，再執行當前的日志 這意味著coordinator線程并不是僅將日志發送給worker線程，自己也可以回放日志，但是所有可以并行的操作交付由worker線程完成。coordinator線程與worker是典型的生產者與消費者模型。 上述機制實現了基于schema的并行復制存在兩個問題，首先是crash safe功能不好做，因為可能之后執行的事務由于并行復制的關系先完成執行，那么當發生crash的時候，這部分的處理邏輯是比較復雜的。從代碼上看，5.6這里引入了Low-Water-Mark標記來解決該問題，從設計上看（[WL#5569](http://dev.mysql.com/worklog/task/?id=5569)），其是希望借助于日志的冪等性來解決該問題，不過5.6的二進制日志回放還不能實現冪等性。另一個最為關鍵的問題是這樣設計的并行復制效果并不高，如果用戶實例僅有一個庫，那么就無法實現并行回放，甚至性能會比原來的單線程更差。而單庫多表是比多庫多表更為常見的一種情形。