一、緣由：
某天看到主從複制延時的告警有點頻繁，就想着是不是徹底可以解決一下。
一般主從複制，有三個線程參與，都是單線程：Binlog Dump（主） ----->IO Thread （從） -----> SQL Thread（從）。複制出現延遲一般出在兩個地方
1）SQL線程忙不過來（可能需要應用資料量較大，可能和從庫本身的一些操作有鎖和資源的沖突；主庫可以并發寫，SQL線程不可以；主要原因）
2）網絡抖動導緻IO線程複制延遲（次要原因）。
二、解決辦法：
MySQL從5.6開始有了SQL Thread多個的概念，可以并發還原資料，即并行複制技術。
MySQL 5.6中，設定參數slave_parallel_workers = 4(>1)，即可有4個SQL Thread（coordinator線程）來進行并行複制，其狀态為：Waiting for an evant from Coordinator。
但是其并行隻是基于Schema的，也就是基于庫的。如果資料庫執行個體中存在多個Schema，這樣設定對于Slave複制的速度可以有比較大的提升。通常情況下單庫多表是更常見的一種情形，
那基于庫的并發就沒有卵用。其核心思想是：不同schema下的表并發送出時的資料不會互相影響，即slave節點可以用對relay log中不同的schema各配置設定一個類似SQL功能的線程，
來重放relay log中主庫已經送出的事務，保持資料與主庫一緻。
在MySQL 5.7中，引入了基于組送出的并行複制（Enhanced Multi-threaded Slaves），設定參數slave_parallel_workers>0并且global.slave_parallel_type＝‘LOGICAL_CLOCK’，
即可支援一個schema下，slave_parallel_workers個的worker線程并發執行relay log中主庫送出的事務。其核心思想：一個組送出的事務都是可以并行回放（配合binary log group commit）；
slave機器的relay log中 last_committed相同的事務（sequence_num不同）可以并發執行。
其中，變量slave-parallel-type可以有兩個值：DATABASE 預設值，基于庫的并行複制方式；LOGICAL_CLOCK：基于組送出的并行複制方式
MySQL 5.7開啟Enhanced Multi-Threaded Slave配置：
# slave
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=16
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON 至此，MySQL徹底解決了複制延遲問題，可喜可賀！
三、參考文檔
官方文檔：https://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html
Inside君的文章：http://www.ttlsa.com/mysql/mysql-5-7-enhanced-multi-thread-salve/