1. 主從同步的延遲的原因
我們知道，一個服務器開放Ｎ個鏈接給客戶端來連接的，這樣有會有大併發的更新操作, 但是從服務器的裡面讀取binlog 的線程僅有一個，當某個SQL在從服務器上執行的時間稍長 或者由於某個SQL要進行鎖表就會導致，主服務器的SQL大量積壓，未被同步到從服務器裡。這就導致了主從不一致，也就是主從延遲。
2. 主從同步延遲的解決辦法
實際上主從同步延遲根本沒有什麼一招制敵的辦法， 因為所有的SQL必須都要在從服務器裡面執行一遍，但是主服務器如果不斷的有更新操作源源不斷的寫入， 那麼一旦有延遲產生， 那麼延遲加重的可能性就會原來越大。 當然我們可以做一些緩解的措施。
a. 我們知道因為主服務器要負責更新操作， 他對安全性的要求比從服務器高， 所有有些設置可以修改，比如sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之類的設置，而slave則不需要這麼高的數據安全，完全可以講sync_binlog設置為0或者關閉binlog，innodb_flushlog， innodb_flush_log_at_trx_commit也可以設置為0來提高sql的執行效率 這個能很大程度上提高效率。另外就是使用比主庫更好的硬件設備作為slave。
b. 就是把，一臺從服務器當度作為備份使用，而不提供查詢，那邊他的負載下來了， 執行relay log 裡面的SQL效率自然就高了。
c. 增加從服務器嘍，這個目的還是分散讀的壓力， 從而降低服務器負載。
3. 判斷主從延遲的方法
MySQL提供了從服務器狀態命令，可以通過 show slave status 進行查看，比如可以看看Seconds_Behind_Master參數的值來判斷，是否有發生主從延時。
其值有這麼幾種：
NULL - 表示io_thread或是sql_thread有任何一個發生故障，也就是該線程的Running狀態是No,而非Yes.
0 - 該值為零，是我們極為渴望看到的情況，表示主從複製狀態正常
閱讀更多 愛踢人生 的文章
