MySQL復制被普遍認為是十分有效的，主服務器進行更改後，從服務器可在幾秒內做出相應的改動。但如果發生兩者之間同步緩慢的問題， 那麼主要有以下原因：
從結點磁盤問題： 復制操作對每個數據庫都是由一個線程來完成，通常執行變更時的滯後是由磁盤延遲引起的。在這種情況下，您應該考慮使用SSD加速這個過程。
帶寬低/網絡延遲高： 如果兩個服務器位於遠程位置高延遲的情況下）或服務器之間的存在帶寬較低的問題，我們應使用下面的方法之一或者兩者結合使用，以最大限度地減少服務器間通信量。
使用基於語句的復制：基於行的復制會為數據庫中每一行的變更創建一個SQL 語句。基於語句的復制是應用程序發送的實際SQL語句的記錄。通常基於語句的復制在記錄大小方面更為有效。然而，你應該意識到，當你使用UPDATE ... LIMIT1時，基於語句的復制可能並不十分有效
壓縮通信量： MySQL支持使用 slave_compressed_protocol參數進行日志壓縮復制。這種方法將減少高達80%的服務器之間的通信。然而，壓縮是計算密集型的，所以你應該意識到這樣會產生一些額外的CPU利用率這通常不屬於數據庫中的問題）。這個參數應該在兩個服務器上都啟用：
動態的從MySQL命令行輸入：SET GLOBALslave_compressed_protocol = 1;
在MySQL配置文件中進行配置：
- #compress master-slave communication
- slave_compressed_protocol = 1
最起碼，要理解你的復制行為為何滯後，然後了解如何使用正確的方法來解決滯後問題。是的，它就是這麼容易，且十分有效。
