大多數情況是正常的，只是偶爾會出現很慢的情況
-
網路問題
-
資料庫在重繪臟頁
-
獲取鎖失敗，我們可以用 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的增多，
系統判斷是否走索引，掃描行數的預測其實只是原因之一，這條查詢陳述句是否需要使用使用臨時表、是否需要排序等也是會影響系統的選擇的，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/54239.html
標籤：MySQL
下一篇：sql server的記憶體問題