前言：本文教你mysql延遲問題和資料刷盤分析！
一、mysql複製流程
官方文件流程如下：
mysql延遲問題和資料刷盤策略
1、絕對的延時，相對的同步
2、純寫操作，線上標準配置下，從庫壓力大於主庫，最起碼從庫有relaylog的寫入。
二、mysql延遲問題分析
1、主庫dml請求頻繁
原因：主庫併發寫入資料，而從庫為單執行緒應用日誌，很容易造成relaylog堆積，產生延遲。
解決思路：做sharding，打散寫請求。考慮公升級到mysql5.7+，開啟基於邏輯時鐘的並行複製。
2、主庫執行大事務
原因：類似主庫花費很長時間更新了一張大表，在主從庫配置相近的情況下，從庫也需要花幾乎同樣的時間更新這張大表，此時從庫延遲開始堆積，後續的events無法更新。
解決思路：拆分大事務，及時提交。
3、主庫對大表執行ddl語句
原因：ddl未開始執行，被阻塞，檢查到位點不變；ddl正在執行，單執行緒應用導致延遲增加，位點不變。
解決思路：找到被阻塞ddl或是寫操作的查詢，乾掉該查詢，讓ddl正常在從庫上執行；業務低峰期執行，盡量使用支援onlineddl的高版本mysql。
4、主從例項配置不一致
原因：硬體上：主庫例項伺服器使用ssd，而從庫例項伺服器使用普通sas盤、cpu主頻不一致等；配置上：如raid卡寫策略不一致，os核心引數設定不一致，mysql落盤策略(innodb_flush_log_at_trx_commit和sync_binlog等)不一致等
解決思路：盡量統一db機器的配置（包括硬體及選項引數）；甚至對於某些olap業務，從庫例項硬體配置高於主庫等。
5、從庫自身壓力過大
原因：從庫執行大量select請求，或業務大部分select請求被路由到從庫例項上，甚至大量olap業務，或者從庫正在備份等，此時可能造成cpu負載過高，io利用率過高等，導致sqlthread應用過慢。
也可以調整innodb_flush_log_at_trx_commit=0和sync_binlog=0刷盤引數來緩解io壓力來降低主從延遲。
三、大促期間cpu過高問題
現象：高併發導致cpu負載過高，處理請求時間拉長，逐步積壓，最終導致服務不可用；大量的慢sql導致cpu負載過高。
解決思路：
基本上是禁止或是慎重考慮資料庫主從切換，這個解決不了根本問題，需要研發配合**sql問題，也可以服務降級，容器的話可以動態擴容cpu；和業務協商啟動pt-kill查殺唯讀慢sql；檢視是否可以通過增加一般索引或是聯合索引來解決慢sql問題，但此時要考慮ddl對資料庫影響。
四、innodb刷盤策略
mysql的innodb_flush_method這個引數控制著innodb資料檔案及redolog的開啟、刷寫模式，對於這個引數，文件上是這樣描述的：
有三個值：fdatasync(預設)，o_dsync，o_direct
預設是fdatasync，呼叫fsync()去刷資料檔案與redolog的buffer
為o_dsync時，innodb會使用o_sync方式開啟和刷寫redolog,使用fsync()刷寫資料檔案
為o_direct時，innodb使用o_direct開啟資料檔案，使用fsync()刷寫資料檔案跟redolog
首先檔案的寫操作包括三步：open,write,flush
上面最常提到的fsync(intfd)函式，該函式作用是flush時將與fd檔案描述符所指檔案有關的buffer刷寫到磁碟，並且flush完元資料資訊(比如修改日期、建立日期等)才算flush成功。
使用o_dsync方式開啟redo檔案表示當write日誌時，資料都write到磁碟，並且元資料也需要更新，才返回成功。
o_direct則表示我們的write操作是從mysqlinnodbbuffer裡直接向磁碟上寫。
這三種模式寫資料方式具體如下：
fdatasync模式：寫資料時，write這一步並不需要真正寫到磁碟才算完成（可能寫入到作業系統buffer中就會返回完成），真正完成是flush操作，buffer交給作業系統去flush,並且檔案的元資料資訊也都需要更新到磁碟。
o_dsync模式：寫日誌操作是在write這步完成，而資料檔案的寫入是在flush這步通過fsync完成
o_direct模式：資料檔案的寫入操作是直接從mysqlinnodbbuffer到磁碟的，並不用通過作業系統的緩衝，而真正的完成也是在flush這步,日誌還是要經過os緩衝。
mysql延遲問題和資料刷盤策略
1、在類unix作業系統中，檔案的開啟方式為o_direct會最小化緩衝對io的影響，該檔案的io是直接在使用者空間的buffer上操作的，並且io操作是同步的，因此不管是read()系統呼叫還是write()系統呼叫，資料都保證是從磁碟上讀取的；所以io方面壓力最小，對於cpu處理壓力上也最小，對物理記憶體的占用也最小；但是由於沒有作業系統緩衝的作用，對於資料寫入磁碟的速度會降低明顯（表現為寫入響應時間的拉長），但不會明顯造成整體sql請求量的降低（這有賴於足夠大的innodb_buffer_pool_size）。
2、o_dsync方式表示以同步io的方式開啟檔案，任何寫操作都將阻塞到資料寫入物理磁碟後才返回。這就造成cpu等待加長，sql請求吞吐能力降低，insert時間拉長。
3、fsync(intfiledes)函式只對由檔案描述符filedes指定的單一檔案起作用，並且等待寫磁碟操作結束，然後返回。fdatasync(intfiledes)函式類似於fsync，但它只影響檔案的資料部分。而除資料外，fsync還會同步更新檔案的元資訊到磁碟。
o_dsync對cpu的壓力最大，datasync次之，o_direct最小；整體sql語句處理效能和響應時間看，o_dsync較差；o_direct在sql吞吐能力上較好（僅次於datasync模式），但響應時間卻是最長的。
預設datasync模式，整體表現較好，因為充分利用了作業系統buffer和innodb_buffer_pool的處理效能，但帶來的負面效果是free記憶體降低過快，最後導致頁交換頻繁，磁碟io壓力大，這會嚴重影響大併發量資料寫入的穩定性。
減少mysql主從資料同步延遲問題的詳解
基於區域網的master sl e機制在通常情況下已經可以滿足 實時 備份的要求了。如果延遲比較大，就先確認以下幾個因素 1.網路延遲 2.master負載 3.sl e負載 一般的做程式設計客棧法是，使用多台sl e來分攤讀請求，再從這些sl e中取一台專用的伺服器，只作為備份用，不進行其他任何操...
mysql資料庫從庫同步延遲的問題
在從伺服器上執行show sl e status 可以檢視到很多同步的引數，我們需要特別注意的引數如下,希望文章對各位會有所幫助。在從伺服器上執行show sl e status 可以檢視到很多同步的引數，我們需要特別注意的引數如下 master log file sl e中的i o執行緒當前正在讀...
Mysql分頁資料顯示總數恒為1問題的分析與解決
1.1 問題描述 doma連線mysql資料庫進行分頁時，查詢出來的總資料顯示總是為1 不是想要的資料結果 介面現象如下 問題分析 doma呼叫mysql語句時會自動在sql語句中加入sql calc found rows關鍵字，然後配合found rows 函式的使用，統計出去除limit限制條件...