大多數情況是正常的，只是偶爾會出現很慢的情況 網路問題 資料庫在刷新臟頁 獲取鎖失敗，我們可以用 show processlist這個命令來查看當前的狀態 刷臟頁有下麵4種場景（後兩種不用太關註“性能”問題）： redolog寫滿了：redo log 里的容量是有限的，如果資料庫一直很忙，更新又很頻 ...
大多數情況是正常的，只是偶爾會出現很慢的情況
-
網路問題
-
資料庫在刷新臟頁
-
獲取鎖失敗，我們可以用 show processlist這個命令來查看當前的狀態
刷臟頁有下麵4種場景（後兩種不用太關註“性能”問題）：
-
redolog寫滿了：redo log 里的容量是有限的，如果資料庫一直很忙，更新又很頻繁，這個時候 redo log 很快就會被寫滿了，這個時候就沒辦法等到空閑的時候再把數據同步到磁碟的，只能暫停其他操作，全身心來把數據同步到磁碟中去的，而這個時候，就會導致我們平時正常的SQL語句突然執行的很慢，alter table 可能造成臟頁過多。所以說，資料庫在在同步數據到磁碟的時候，就有可能導致我們的SQL語句執行的很慢了。
-
記憶體不夠用了：如果一次查詢較多的數據，恰好碰到所查數據頁不在記憶體中時，需要申請記憶體，而此時恰好記憶體不足的時候就需要淘汰一部分記憶體數據頁，如果是乾凈頁，就直接釋放，如果恰好是臟頁就需要刷臟頁。
-
MySQL 認為系統“空閑”的時候/ Master Thread：這時系統IO壓力不大，每秒或每十秒的非同步刷新操作
-
MySQL 正常關閉的時候：這時候，MySQL 會把記憶體的臟頁都 flush 到磁碟上，這樣下次 MySQL 啟動的時候，就可以直接從磁碟上讀數據，啟動速度會很快。
在數據量不變的情況下，這條SQL語句一直以來都執行的很慢
- 沒有用上索引：例如該欄位沒有索引；由於對欄位進行運算、函數操作導致無法用索引。
- 資料庫選錯了索引
有索引但是最終卻選擇全表掃描的原因：
例如以下SQL：
select * from t where 100 < c and c < 100000;
索引的選擇判斷來源於系統的預測，也就是說，如果要走 c 欄位索引的話，系統會預測走 c 欄位索引大概需要掃描多少行。如果預測到要掃描的行數很多（大概接近於20%），它可能就不走索引而直接掃描全表了。因為索引c將標識多一次的輔助索引的查詢，造成IO的增多。
系統判斷是否走索引，掃描行數的預測其實只是原因之一，這條查詢語句是否需要使用使用臨時表、是否需要排序等也是會影響系統的選擇的。
