MySQL 刷髒頁問題

mysql的刷髒頁問題

平時的工作中，不知道你有沒有遇到過這樣的場景，一條 sql 語句，正常執行的時候特別快，但是有時也不知道怎麼回事，它就會變得特別慢，並且這樣的場景很難復現，它不只隨機，而且持續時間還很短。

當記憶體資料頁跟磁碟資料頁內容不一致的時候，我們稱這個記憶體頁為「髒頁」。記憶體資料寫入到磁碟後，記憶體和磁碟上的資料頁的內容就一致了，稱為「乾淨頁」。

平時執行很快的更新操作，其實就是在寫記憶體和日誌，而 mysql 偶爾「抖」一下的那個瞬間，可能就是在刷髒頁（flush）。

那麼，什麼情況會引發資料庫的 flush 過程呢？

第一種場景是innodb 的 redo log 寫滿了，這時候系統會停止所有更新操作，把 checkpoint 往前推進，redo log 留出空間可以繼續寫。

第二種場景對應的就是系統記憶體不足。當需要新的記憶體頁，而記憶體不夠用的時候，就要淘汰一些資料頁，空出記憶體給別的資料頁使用。如果淘汰的是「髒頁」，就要先將髒頁寫到磁碟。

第三種場景對應的就是 mysql 認為系統「空閒」的時候。當然，mysql忙起來可是會很快就能把redo log 記滿的，所以要合理地安排時間，即使是忙的時候，也要見縫插針地找時間，只要有機會就刷一點「髒頁」。

第四種場景對應的就是 mysql 正常關閉的情況。這時候，mysql 會把記憶體的髒頁都 flush 到磁碟上，這樣下次 mysql 啟動的時候，就可以直接從磁碟上讀資料，啟動速度會很快。

接下來，你可以分析一下上面四種場景對效能的影響。

其中，第三種情況是屬於 mysql 空閒時的操作，這時系統沒什麼壓力，而第四種場景是資料庫本來就要關閉了。這兩種情況下，你不會太關注「效能」問題。所以這裡，我們主要來分析一下前兩種場景下的效能問題。

第一種是「redo log 寫滿了，要 flush 髒頁」，這種情況是 innodb 要盡量避免的。因為出現這種情況的時候，整個系統就不能再接受更新了，所有的更新都必須堵住。如果你從監控上看，這時候更新數會跌為 0。

第二種是「記憶體不夠用了，要先將髒頁寫到磁碟」，這種情況其實是常態。innodb 用緩衝池（buffer pool）管理記憶體，緩衝池中的記憶體頁有三種狀態：

innodb 的策略是盡量使用記憶體，因此對於乙個長時間執行的庫來說，未被使用的頁面很少。

而當要讀入的資料頁沒有在記憶體的時候，就必須到緩衝池中申請乙個資料頁。這時候只能把最久不使用的資料頁從記憶體中淘汰掉：如果要淘汰的是乙個乾淨頁，就直接釋放出來復用；但如果是髒頁呢，就必須將髒頁先刷到磁碟，變成乾淨頁後才能復用。

所以，刷髒頁雖然是常態，但是出現以下這兩種情況，都是會明顯影響效能的：

乙個查詢要淘汰的髒頁個數太多，會導致查詢的響應時間明顯變長；

日誌寫滿，更新全部堵住，寫效能跌為 0，這種情況對敏感業務來說，是不能接受的。

所以，innodb 需要有控制髒頁比例的機制，來盡量避免上面的這兩種情況。

innodb 刷髒頁的控制策略

首先，你要正確地告訴 innodb 所在主機的 io 能力，這樣 innodb 才能知道需要全力刷髒頁的時候，可以刷多快。

這就要用到 innodb_io_capacity 這個引數了，它會告訴 innodb 你的磁碟能力。

現在你知道了，innodb 會在後台刷髒頁，而刷髒頁的過程是要將記憶體頁寫入磁碟。所以，無論是你的查詢語句在需要記憶體的時候可能要求淘汰乙個髒頁，還是由於刷髒頁的邏輯會占用 io 資源並可能影響到了你的更新語句，都可能是造成你從業務端感知到 mysql「抖」了一下的原因。

要盡量避免這種情況，你就要合理地設定 innodb_io_capacity 的值，並且平時要多關注髒頁比例(引數 innodb_max_dirty_pages_pct)，不要讓它經常接近 75%。