背景

時(shí)間過得太快了，春節(jié)假期感覺光速般就結(jié)束了，轉(zhuǎn)眼間就要繼續(xù)搬磚上班了。緊接著很快就要進(jìn)入金三銀四的求職面試高峰期，程序猿小楓還沒有找到令自己感到滿意的工作。就算是在過年放假期間也在拼命的準(zhǔn)備技術(shù)面試，這不他又梳理了下之前面試過程中面試官經(jīng)常問到的關(guān)于數(shù)據(jù)庫方面的一道面試題，我們來一起幫小楓看看有沒有遺漏的地方吧。

面試題目——問題

面試官:看你的簡(jiǎn)歷中有提到過曾經(jīng)進(jìn)行過索引優(yōu)化的工作，那我就問問你，假設(shè)數(shù)據(jù)庫表中有索引，但是進(jìn)行SQL數(shù)據(jù)查詢還是很慢，這種情況下應(yīng)該怎么分析查詢慢的原因？

分析

在進(jìn)行數(shù)據(jù)庫查詢的時(shí)候，我們都知道索引可以加快數(shù)據(jù)查詢的效率。但是在實(shí)際的業(yè)務(wù)場(chǎng)景下，經(jīng)常會(huì)遇到即使在表中增加了索引，但是同樣還是會(huì)出現(xiàn)數(shù)據(jù)查詢慢的問題。這就需要具體分析數(shù)據(jù)查詢慢的具體原因到底是什么了。

首先需要進(jìn)行確認(rèn)的就是SQL語句中對(duì)應(yīng)的條件查詢中字段有沒有建立索引。雖然面試官說了有索引，但是不一定SQL語句中的查詢字段有建立索引，所以第一步應(yīng)該進(jìn)行SQL中的字段索引確認(rèn)。如果沒有建立對(duì)應(yīng)的索引可以先嘗試下建立索引再進(jìn)行查詢。如果已經(jīng)有了索引，查詢的字段也是索引字段，那么就要考慮下是不是出現(xiàn)了索引失效的情況。下面我們?cè)倬唧w分析下，看看在哪些場(chǎng)景下會(huì)出現(xiàn)索引失效的情況。

索引失效場(chǎng)景

在分析索引失效場(chǎng)景之前，我們必須要清楚索引結(jié)構(gòu)的特點(diǎn)是什么。關(guān)于Mysql的數(shù)據(jù)庫索引結(jié)構(gòu)在之前的文章中已經(jīng)進(jìn)行了詳細(xì)的分析，可以參見之前的文章。

Mysql數(shù)據(jù)庫索引面試題(程序員基礎(chǔ)技能)

我們來看下Mysql數(shù)據(jù)庫索引的結(jié)構(gòu)特點(diǎn)：

?這里以u(píng)ser_info這張表來作為分析的基礎(chǔ)，在user_info這張表上，我們分別創(chuàng)建了idx_name以及idx_phone二級(jí)索引以及idx_age_address聯(lián)合索引。

CREATE TABLE IF NOT EXISTS `user_info` (
 `id` bigint(20) NOT NULL AUTO_INCREMENT,
 `name` VARCHAR(20) NOT NULL,
 `gender` int(2) NOT NULL,
 `age` int(10) NOT NULL,
 `phone_number` VARCHAR(20) NOT NULL,
 `address` VARCHAR(40) NOT NULL,
  PRIMARY KEY ( `id` ),
  KEY `idx_name`(`name`),
  KEY `idx_phone`(`phone_number`),
  KEY `idx_age_address`(`age`,`address`)
)ENGINE=InnoDB DEFAULT CHARSET=utf8;

• 1、字段類型不匹配導(dǎo)致的索引失效

進(jìn)行SQL數(shù)據(jù)查詢的時(shí)候，where條件字段類型與實(shí)際表中字段類型不匹配的時(shí)候，Mysql會(huì)進(jìn)行隱式的數(shù)據(jù)類型轉(zhuǎn)換，而類型轉(zhuǎn)換會(huì)使用到內(nèi)置函數(shù)，導(dǎo)致在進(jìn)行數(shù)據(jù)查詢的時(shí)候并沒有使用索引。我們可以使用explain命令查看sql語句?？梢钥吹某鰜碓趉ey欄中，對(duì)應(yīng)的值為null，說明并沒有使用索引進(jìn)行查詢。?

?但是如果在按照phone_number字段為字符串類型進(jìn)行查詢的時(shí)候，Mysql沒有進(jìn)行隱式的類型轉(zhuǎn)換，所以最終還是走了索引。

• 2、被索引字段使用了表達(dá)式計(jì)算

在where中條件使用了條件表達(dá)式的時(shí)候，數(shù)據(jù)表中的索引就失效了，實(shí)際是因?yàn)镸ysql需要將索引字段取出來之后再進(jìn)行表達(dá)式的條件判斷，因而進(jìn)行了全表掃描，導(dǎo)致索引失效。

• 3、被索引字段使用了內(nèi)置函數(shù)

索引字段實(shí)際上是依賴于整個(gè)B+索引樹的遍歷，而索引樹的遍歷又依賴于索引樹底層葉子節(jié)點(diǎn)的有序性。索引保存的是索引列的原始值，如果經(jīng)過函數(shù)計(jì)算，Msql的解釋器無法判斷計(jì)算后的索引在原來的索引樹上是否可以被索引到，因此它就直接放棄使用索引查詢了。

• 4、like使用了%X模糊匹配

使用左模糊匹配以及左右模糊匹配都會(huì)導(dǎo)致索引失效，但是使用右模糊匹配，還是可以走索引查詢的。

由于B+樹按照索引值進(jìn)行排序的，實(shí)際是按照最左前綴進(jìn)行比較，而使用了%作為最左前綴，Mysql無法判斷其有序性，因此只能進(jìn)行全表掃描查詢。

• 5、索引字段不是聯(lián)合索引字段的最左字段

如果數(shù)據(jù)庫表中有聯(lián)合索引的話，我們?cè)赟QL查詢語句中使用的索引字段又不是聯(lián)合索引的最左字段，那么就會(huì)導(dǎo)致索引失效。

實(shí)際上在Mysql中的索引檢索是遵循最左匹配原則的，同時(shí)B+索引樹的葉子節(jié)點(diǎn)的有序性也是建立都在最左匹配原則之上，而上述的4、5兩種情況實(shí)際違反了最左匹配原則，因此Mysql執(zhí)行器則無法使用對(duì)應(yīng)的索引進(jìn)行檢查查詢。

• 6、or分割的條件，如果or左邊的條件存在索引，而右邊的條件沒有索引，不走索引

因?yàn)?OR 的含義就是兩個(gè)只要滿足一個(gè)即可，因此只有一個(gè)條件列進(jìn)行了索引是沒有意義的，只要有條件列沒有進(jìn)行索引，就會(huì)進(jìn)行全表掃描，因此索引的條件列也會(huì)失效。

• 7、in、not in可能會(huì)導(dǎo)致索引失效

這里需要說明的是使用in以及not in走不走索引，實(shí)際和Mysql的版本以及表中的數(shù)據(jù)量有關(guān)系，在8.0之后的版本是走索引的。

總結(jié)

本文根據(jù)面試官的存在索引但是出現(xiàn)數(shù)據(jù)查詢慢的問題為出發(fā)點(diǎn)，總結(jié)了幾種索引失效的場(chǎng)景，希望在大家平時(shí)項(xiàng)目開發(fā)時(shí)遇到類似的問題可以有對(duì)應(yīng)的問題排查方向。導(dǎo)致索引失效的場(chǎng)景歸結(jié)起來實(shí)際就是在索引使用上面存在瑕疵最終導(dǎo)致了索引失效的情況，這就像我們小時(shí)候打拳皇97一樣，遙感和按鈕的組合如果姿勢(shì)不對(duì)，就沒辦法放出我們希望的大招。小楓的求職面試之路還在繼續(xù)，我們一起期待下次小楓還會(huì)遇到怎樣的面試問題吧。

到此這篇關(guān)于Mysql數(shù)據(jù)庫表中為什么有索引卻沒有提高查詢速度的文章就介紹到這了,更多相關(guān)Mysql 數(shù)據(jù)庫表索引內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論