針對一直都這麼慢的情況

如果在資料量一樣大的情況下，這條 SQL 語句每次都執行的這麼慢，那就就要好好考慮下你的 SQL 書寫了，下面我們來分析下哪些原因會導致我們的 SQL 語句執行的很不理想。

我們先來假設我們有一個表，表裡有下面兩個欄位,分別是主鍵 id，和兩個普通欄位 c 和 d。

mysql> CREATE TABLE `t` (  `id` int(11) NOT NULL,  `c` int(11) DEFAULT NULL,  `d` int(11) DEFAULT NULL,  PRIMARY KEY (`id`)) ENGINE=InnoDB;
 

1. 沒用到索引

沒有用上索引，我覺得這個原因是很多人都能想到的，例如你要查詢這條語句

select * from t where 100 <c and c < 100000;

a. 欄位沒有索引

剛好你的 c 欄位上沒有索引，那麼抱歉，只能走全表掃描了，你就體驗不會索引帶來的樂趣了，所以，這回導致這條查詢語句很慢。

b. 欄位有索引，但卻沒有用索引

好吧，這個時候你給 c 這個欄位加上了索引，然後又查詢了一條語句

select * from t where c - 1 = 1000;

我想問大家一個問題，這樣子在查詢的時候會用索引查詢嗎？

不會，如果我們在欄位的左邊做了運算，那麼很抱歉，在查詢的時候，就不會用上索引了，所以呢，大家要注意這種欄位上有索引，但由於自己的疏忽，導致系統沒有使用索引的情況了。

正確的查詢應該如下

select * from t where c = 1000 + 1;

有人可能會說，右邊有運算就能用上索引？難道資料庫就不會自動幫我們優化一下，自動把 c - 1=1000 自動轉換為 c = 1000+1。

c. 函式操作導致沒有用上索引

如果我們在查詢的時候，對欄位進行了函式操作，也是會導致沒有用上索引的，例如

select * from t where pow(c,2) = 1000;

這裡我只是做一個例子，假設函式 pow 是求 c 的 n 次方，實際上可能並沒有 pow(c,2)這個函式。其實這個和上面在左邊做運算也是很類似的。

所以呢，一條語句執行都很慢的時候，可能是該語句沒有用上索引了，不過具體是啥原因導致沒有用上索引的呢，你就要會分析了，我上面列舉的三個原因，應該是出現的比較多的吧。

2. 資料庫自己選錯索引了

我們在進行查詢操作的時候，例如

select * from t where 100 < c and c < 100000;

我們知道，主鍵索引和非主鍵索引是有區別的，主鍵索引存放的值是整行欄位的資料，而非主鍵索引上存放的值不是整行欄位的資料，而且存放主鍵欄位的值。 裡面有說到主鍵索引和非主鍵索引的區別。

思維導圖

果走 c 這個欄位的索引的話，最後會查詢到對應主鍵的值，然後，再根據主鍵的值走主鍵索引，查詢到整行資料返回。

就算你在 c 欄位上有索引，系統也並不一定會走 c 這個欄位上的索引，而是有可能會直接掃描掃描全表，找出所有符合 100 < c and c < 100000 的資料。

系統在執行這條語句的時候，會進行預測：究竟是走 c 索引掃描的行數少，還是直接掃描全表掃描的行數少呢？顯然，掃描行數越少當然越好了，因為掃描行數越少，意味著I/O操作的次數越少。

如果是掃描全表的話，那麼掃描的次數就是這個表的總行數了，假設為 n；而如果走索引 c 的話，我們通過索引 c 找到主鍵之後，還得再通過主鍵索引來找我們整行的資料，也就是說，需要走兩次索引。而且，我們也不知道符合 100 c < and c < 10000 這個條件的資料有多少行，萬一這個表是全部資料都符合呢？這個時候意味著，走 c 索引不僅掃描的行數是 n，同時還得每行資料走兩次索引。

       系統是通過索引的區分度來判斷的，一個索引上不同的值越多，意味著出現相同數值的索引越少，意味著索引的區分度越高。我們也把區分度稱之為基數，即區分度越高，基數越大。所以呢，基數越大，意味著符合 100 < c and c < 10000 這個條件的行數越少。

所以呢，一個索引的基數越大，意味著走索引查詢越有優勢。

索引的基數，索引系統是通過遍歷部分資料，也就是通過取樣的方式，來預測索引的基數的。

重點來了，居然是取樣，那就有可能出現失誤的情況，也就是說，c 這個索引的基數實際上是很大的，但是取樣的時候，卻很不幸，把這個索引的基數預測成很小。例如你取樣的那一部分資料剛好基數很小，然後就誤以為索引的基數很小。然後系統就不走 c 索引了，直接走全部掃描了。

所以呢，說了這麼多，得出結論：由於統計的失誤，導致系統沒有走索引，而是走了全表掃描，而這，也是導致我們 SQL 語句執行的很慢的原因。

這裡宣告一下，系統判斷是否走索引，掃描行數的預測其實只是原因之一，這條查詢語句是否需要使用使用臨時表、是否需要排序等也是會影響系統的選擇的。

不過呢，我們有時候也可以通過強制走索引的方式來查詢，例如

select * from t force index(a) where c < 100 and c < 100000;

我們也可以通過

show index from t;

來查詢索引的基數和實際是否符合，如果和實際很不符合的話，我們可以重新來統計索引的基數，可以用這條命令

analyze table t;

來重新統計分析。

既然會預測錯索引的基數，這也意味著，當我們的查詢語句有多個索引的時候，系統有可能也會選錯索引，這也可能是 SQL 執行的很慢的一個原因。

下面做一個總結。

總結

以上是我的總結與理解，最後一個部分，我怕很多人不大懂資料庫居然會選錯索引，所以我詳細解釋了一下，下面我對以上做一個總結。

一個 SQL 執行的很慢，我們要分兩種情況討論：

1. 大多數情況下很正常，偶爾很慢，則有如下原因

a. 資料庫在重新整理髒頁，例如 redo log 寫滿了需要同步到磁碟。

b. 執行的時候，遇到鎖，如表鎖、行鎖。

2. 這條 SQL 語句一直執行的很慢，則有如下原因。

a. 沒有用上索引：例如該欄位沒有索引；由於對欄位進行運算、函式操作導致無法用索引。

b. 資料庫選錯了索引。

按鍵查詢還是比較常見的效能提升手段。 個人總結的優化原則是： 做事快（索引、並行、快盤、高效表連線等） 做事少（資料拆分減少訪問資料量、過濾性強的條件、去除或降低不必要執行的語句量等） 無等待（熱塊打散、鎖爭用避免等）

出處：https://juejin.im/post/5cc84cb6518825250e