mysql查詢速度慢的原因［整理版］

標籤：

在以前的部落格中陸續記錄了有關查詢效率方面的文章。今天在整理一下，寫上自己的一些心得記錄如下：
常見查詢慢的原因常見的話會有如下幾種：
1、沒有索引或沒有用到索引。
PS：索引用來快速地尋找那些具有特定值的記錄，所有MySQL索引都以B-樹的形式儲存。如果沒有索引，執行查詢時MySQL必須從第一個記錄開始掃描整個表 的所有記錄，直至找到符合要求的記錄。表裡面的記錄數量越多，這個操作的代價就越高。如果作為搜尋條件的列上已經建立了索引，MySQL無需掃描任何記錄 即可迅速得到目標記錄所在的位置。如果表有1000個記錄，通過索引尋找記錄至少要比順序掃描記錄快100倍。
索引類型：
普通索引：這是最基本的索引類型，沒唯一性之類的限制。
唯一性索引：和普通索引基本相同，但所有的索引列只能出現一次，保持唯一性。
主鍵：主鍵是一種唯一索引，但必須指定為"PRIMARY KEY"。
全文索引：MYSQL從3.23.23開始支援全文索引和全文檢索索引。在MYSQL中，全文索引的索引類型為FULLTEXT。全文索引可以在VARCHAR或者TEXT類型的列上建立。
2、IO輸送量小形成了瓶頸。
PS：這是從系統層來分析MYSQL是比較耗IO的。一般資料庫監控也是比較關注IO。
監控命令：$iostat -d -k 1 10
參數 -d 表示，顯示裝置（磁碟）使用狀態；-k某些使用block為單位的列強制使用Kilobytes為單位；1 10表示，資料顯示每隔1秒重新整理一次，共顯示10次。
3、記憶體不足
監控記憶體使用量：vmstat [-n] [延時[次數]]
Memory

swpd: 切換到交換記憶體上的記憶體(預設以KB為單位)• 如果 swpd 的值不為0，或者還比較大，比如超過100M了，但是si, so 的值長期為0，這種情況我們可以不用擔心，不會影響系統效能。free: 閒置實體記憶體buff: 作為buffer cache的記憶體，對塊裝置的讀寫進行緩衝cache: 作為page cache的記憶體, 檔案系統的cache• 如果 cache 的值大的時候，說明cache住的檔案數多，如果頻繁訪問到的檔案都能被cache住，那麼磁碟的讀IO bi 會非常小。
4、網路速度慢
ping IP -t 查看是否有丟包。
5、一次查詢的資料量過大。
比如沒有分頁查詢，一次提取上萬條記錄。資料庫有可能卡死。
6、出現死結
所謂死結: 是指兩個或兩個以上的進程在執行過程中,因爭奪資源而造成的一種互相等待的現象,若無外力作用,它們都將無法推進下去.
Show innodb status檢查引擎狀態 ,可以看到哪些語句產生死結。
執行show  processlist找到死結線程號.然後Kill　processNo
7、返回了不必要的行或列
一般查詢SQL語句一定要將欄位明確指定。而不要使用*進行查詢
8、注意UNion和UNion all 的區別。UNION all好
UNION在進行錶鏈接後會篩選掉重複的記錄，所以在錶鏈接後會對所產生的結果集進行排序運算，重複資料刪除的記錄再返回結果。所以union all的效率肯定要高！
9、

mysql查詢速度慢的原因［整理版］