(1)如何實現mysql的讀寫分離？
其實很簡單，就是基於主從複製架構，簡單來說，就搞乙個主庫，掛多個從庫，然後我們就單單只是寫主庫，然後主庫會自動把資料給同步到從庫上去。
(2)mysql主從複製原理的是啥？
主庫將變更寫binlog日誌，然後從庫連線到主庫之後，從庫有乙個io執行緒，將主庫的binlog日誌拷貝到自己本地，寫入乙個中繼日誌中。接著從庫中有乙個sql執行緒會從中繼日誌讀取binlog，然後執行binlog日誌中的內容，也就是在自己本地再次執行一遍sql，這樣就可以保證自己跟主庫的資料是一樣的。
這裡有乙個非常重要的一點，就是從庫同步主庫資料的過程是序列化的，也就是說主庫上並行的操作，在從庫上會序列執行。所以這就是乙個非常重要的點了，由於從庫從主庫拷貝日誌以及序列執行sql的特點，在高併發場景下，從庫的資料一定會比主庫慢一些，是有延時的。所以經常出現，剛寫入主庫的資料可能是讀不到的，要過幾十毫秒，甚至幾百毫秒才能讀取到。
而且這裡還有另外乙個問題，就是如果主庫突然宕機，然後恰好資料還沒同步到從庫，那麼有些資料可能在從庫上是沒有的，有些資料可能就丟失了。
所以mysql實際上在這一塊有兩個機制，乙個是半同步複製，用來解決主庫資料丟失問題；乙個是並行複製，用來解決主從同步延時問題。
這個所謂半同步複製，semi-sync複製，指的就是主庫寫入binlog日誌之後，就會將強制此時立即將資料同步到從庫，從庫將日誌寫入自己本地的relay log之後，接著會返回乙個ack給主庫，主庫接收到至少乙個從庫的ack之後才會認為寫操作完成了。
所謂並行複製，指的是從庫開啟多個執行緒，並行讀取relay log中不同庫的日誌，然後並行重放不同庫的日誌，這是庫級別的並行。
主從複製的原理
主從延遲問題產生的原因
主從複製的資料丟失問題，以及半同步複製的原理
並行複製的原理，多庫併發重放relay日誌，緩解主從延遲問題
(3)mysql主從同步延時問題(精華)
線上確實處理過因為主從同步延時問題，導致的線上的bug，小型的生產事故
show status，seconds_behind_master，你可以看到從庫複製主庫的資料落後了幾ms
其實這塊東西我們經常會碰到，就比如說用了mysql主從架構之後，可能會發現，剛寫入庫的資料結果沒查到，結果就完蛋了。。。。
所以實際上你要考慮好應該在什麼場景下來用這個mysql主從同步，建議是一般在讀遠遠多於寫，而且讀的時候一般對資料時效性要求沒那麼高的時候，用mysql主從同步
所以這個時候，我們可以考慮的乙個事情就是，你可以用mysql的並行複製，但是問題是那是庫級別的並行，所以有時候作用不是很大
所以這個時候。。通常來說，我們會對於那種寫了之後立馬就要保證可以查到的場景，採用強制讀主庫的方式，這樣就可以保證你肯定的可以讀到資料了吧。其實用一些資料庫中介軟體是沒問題的。
一般來說，如果主從延遲較為嚴重
分庫，將乙個主庫拆分為4個主庫，每個主庫的寫併發就500/s，此時主從延遲可以忽略不計
開啟mysql支援的並行複製，多個庫並行複製，如果說某個庫的寫入併發就是特別高，單庫寫併發達到了2000/s，並行複製還是沒意義。28法則，很多時候比如說，就是少數的幾個訂單表，寫入了2000/s，其他幾十個表10/s。
重寫**，寫**的同學，要慎重，當時我們其實短期是讓那個同學重寫了一下**，插入資料之後，直接就更新，不要查詢
如果確實是存在必
mysql讀寫分離
5.讀寫分離適用與讀遠大於寫的場景，如果只有一台伺服器，當select很多時，update和delete會被這些select訪問中的資料堵塞，等待select結束，併發效能不高。對於寫和讀比例相近的應用，應該部署雙主相互複製。6.可以在從庫啟動是增加一些引數來提高其讀的效能，例如 skip inno...
讀寫分離 MySQL
1 what 讀寫分離 讀寫分離，基本的原理是讓主資料庫處理事務性增 改 刪操作 insert update delete 而從資料庫處理select查詢操作。資料庫複製被用來把事務性操作導致的變更同步到集群中的從資料庫。2 why 那麼為什麼要讀寫分離呢？因為資料庫的 寫 寫10000條資料到or...
mysql讀寫分離
在資料庫集群架構中，讓主庫負責處理事務性查詢，而從庫只負責處理select查詢，讓兩者分工明確達到提高資料庫整體讀寫效能。當然，主資料庫另外乙個功能就是負責將事務性查詢導致的資料變更同步到從庫中，也就是寫操作。即主從複製和讀寫分離是離不開的 1 分攤伺服器壓力，提高機器的系統處理效率 讀寫分離適用於...