前 言

我們講解了sql優(yōu)化的一般流程，不管是優(yōu)化join語句、where語句、聚合函數(shù)還是排序操作，核心在于利用索引來優(yōu)化sql語句，但是，大家以為我們?yōu)樽侄蝿?chuàng)建了索引之后，索引就一定會生效嗎？

當然不是的，因為索引可能會失效。

那索引為什么會失效呢？失效之后會導致什么樣的后果呢？這一節(jié)，我們利用當下的問題，也就是千萬級的訂單表查詢居然需要耗費3s的時間，通過這個問題我們來一探究竟。

目前為止，我們已經初步確定問題原因，說白了就是sql沒有正常使用到索引，因為單表千萬級的數(shù)據，B+樹基本也就是三到四層，那么如果正常使用到索引的話，幾十毫秒sql就執(zhí)行完畢了。

所以這條sql，肯定是沒有使用到索引，說白了就是索引失效了，此時就會發(fā)生大量的磁盤IO，最終就會導致sql查詢時間達到了3s。

索引失效會導致什么后果？

首先我們先來看下，索引失效的話，會導致什么后果呢？我們用之前文章出現(xiàn)過的圖來舉例

我們可以看到，一個數(shù)據表中的數(shù)據，是通過多個數(shù)據頁的方式存儲起來的，并且數(shù)據頁之間是通過雙向鏈表的方式連接起來的 。

就以訂單表舉例，如果訂單表中的數(shù)據達到上千萬數(shù)據的級別了，這個時候，存放訂單數(shù)據的數(shù)據頁數(shù)量，就不是100個數(shù)據頁這么少了，可能會有幾萬甚至幾十萬個數(shù)據頁。

如果我們不用上索引的話，就意味著我們要面臨加載幾萬甚至幾十萬個數(shù)據頁的風險，這個過程同時會導致大量的磁盤IO，是非常耗費性能，影響我們查詢的效率的。

所以，我們也可以知道，為什么隨著表中的數(shù)據量越來越大，就會導致查詢的速度會越來越慢了。

而索引在這個時候，就變得越來越重要了，關鍵在于，我們怎樣優(yōu)化我們的sql語句，讓sql語句查詢數(shù)據的時候，盡量利用索引來查詢數(shù)據。

sql優(yōu)化案例實戰(zhàn)

體驗下無索引的查詢效率

在進行sql優(yōu)化之前，我們先來體驗下沒有索引時，我們sql的一個查詢效率。

（1）無索引的查詢效率

當前表的數(shù)據量為2500W，查詢時間已經消耗了65秒

（2）無索引的執(zhí)行計劃

通過explain分析該查詢sql的執(zhí)行計劃，我們可以看到這條sql進行了全表掃描。

(3) sql執(zhí)行慢會發(fā)生什么連鎖反應？

模擬并發(fā)請求時，會發(fā)現(xiàn)由于sql查詢時間過長，導致數(shù)據庫連接數(shù)快速被消耗完，最終導致后面的sql再執(zhí)行的時候就被拒絕連接了。

體驗下有索引的查詢效率

（1）創(chuàng)建索引

我們可以給order_no字段加上索引，如下圖：

（2）有索引的查詢效率

為order_no字段添加上索引后再試試查詢，看看效率有多大的提高。

我們可以發(fā)現(xiàn)同樣的sql在無索引和有索引的情況，查詢效率差距是非常大的。所以在遇到大表查詢慢的場景不妨先查看一下查詢字段是否有添加上合適的索引。

（3）有索引的執(zhí)行計劃

通過執(zhí)行計劃可以看到加索引后，只掃描了一行就找到了需要查詢的數(shù)據

sql優(yōu)化案例：隱式轉換導致索引失效

（1）正常使用到索引的情況

在項目中訂單號的類型為String,當我們SQL語句編寫正確的情況，查詢效率是很快的

(2) 隱式轉換導致索引失效

當我們錯誤的使用數(shù)值類型的訂單號去進行查詢時，我們看一下查詢時間。

通過圖中的執(zhí)行情況，執(zhí)行效率確是天差地別的，查詢時間竟然需要整整24秒！

（3）通過explain查看索引失效的執(zhí)行計劃

通過explain分析這條SQL的執(zhí)行計劃，我們會發(fā)現(xiàn)雖然order_no字段上我們設置了索引，但這條查詢依然進行了全表掃描，說白了就是根本沒有用到索引，因此查詢效率才會大減。

結束語

最后，簡單做一個說明，那就是實際的sql優(yōu)化是比較復雜的，可能還會涉及到鎖、內存和網絡，我們這里只是列舉了sql優(yōu)化中需要注意的2個點而已，而這2個點只是sql優(yōu)化的一小部分。之所以提出來這2個點，主要是為了達到拋磚引玉的效果，就是遇到問題時，大家首先要聚焦在sql優(yōu)化這里，而不是說先考慮一些高大上的解決方案。?