背景

在一個(gè)表中，dataTime字段設(shè)置是varchar類型，存入的數(shù)據(jù)是日期格式的數(shù)據(jù)，并且為該字段設(shè)置了索引。但是在日志記錄中，有一條關(guān)于該表的慢查詢。查詢語(yǔ)句為:
select * from digitaltwin_meteorological where dataTime > '2021-10-15';
explain分析sql語(yǔ)句，發(fā)現(xiàn)sql語(yǔ)句執(zhí)行了全表掃描。為何sql中用了dataTime索引列，為啥還走全表掃描呢？

探索

一:起初，認(rèn)為是dataTime字段類型為varchar，所以mysql在索引排序時(shí)，按照字符串順序進(jìn)行排序了，而不是日期大小順序進(jìn)行排序的，所以在范圍查詢時(shí)，并不能按照日期順序進(jìn)行索引的范圍分區(qū)。于是把dataTime改為datatime類型，在分析語(yǔ)句，發(fā)現(xiàn)還是全表掃描。

二:改變查詢條件的值，

 select count(*) from digitaltwin_meteorological where dataTime > '2021-10-15';

執(zhí)行結(jié)果為3910。

EXPLAIN select * from digitaltwin_meteorological where dataTime > '2021-10-15';

sql語(yǔ)句分析結(jié)果為全表掃描:

我們把查詢條件改為16號(hào)，看有多少條數(shù)據(jù):

 select count(*) from digitaltwin_meteorological where dataTime > '2021-10-16';

查詢結(jié)果為2525，下面我們分析16號(hào)的查詢語(yǔ)句:

EXPLAIN select * from digitaltwin_meteorological where dataTime > '2021-10-16';

執(zhí)行結(jié)果為range查詢，利用到了索引:

由此可見(jiàn)，當(dāng)查詢出來(lái)的記錄條數(shù)多時(shí)，mysql會(huì)走全表掃描，認(rèn)為全表掃描的效率更快。當(dāng)查詢出來(lái)的記錄少時(shí)，mysql會(huì)使用索引查詢。
全表的數(shù)據(jù)量為19714條數(shù)據(jù)，也就是說(shuō)當(dāng)2525/19714=13%的時(shí)候，mysql走索引查詢。當(dāng)3910/19714=20%的時(shí)候，mysql走全表掃描。

三:我們把dataTime該為了datetime數(shù)據(jù)類型，那么查詢條件是否還需要加引號(hào)呢，我們把dataTime查詢條件的引號(hào)去掉，看結(jié)果:

EXPLAIN select * from digitaltwin_meteorological where dataTime > 2021-10-16;

可見(jiàn)，去掉引號(hào)后，又成了全表掃描。所以說(shuō)，不管字段類型是varchar還是datetime，查詢條件的值都需要加引號(hào)。而不加引號(hào)，mysql會(huì)把這個(gè)值做一些運(yùn)算操作，其實(shí)不加引號(hào)后2021-10-16就不再是16號(hào)的日期了，我們看如下sql：

 select count(*) from digitaltwin_meteorological where dataTime > 2021-10-16;

計(jì)算結(jié)果為19714，全表的數(shù)據(jù)，所以說(shuō)，datetime查詢條件也需要加引號(hào)。

四:如上的分析，都是dataTime在datetime類型情況下的討論。而最初的字段類型是varchar，那么改成varchar類型，如上的結(jié)論還存在嗎，我們修改類型，再執(zhí)行sql:

EXPLAIN select * from digitaltwin_meteorological where dataTime > '2021-10-16';

可以看到，改成varchar類型后，16號(hào)查詢成了全表掃描，而不是range掃描。
把條件改成17號(hào)，看執(zhí)行結(jié)果:

EXPLAIN select * from digitaltwin_meteorological where dataTime > '2021-10-17';

17號(hào)的查詢走了索引查詢。我們看17號(hào)的數(shù)據(jù)量是1749。
所以，在字段類型為varchar時(shí)，1749/19714=9%的情況下，會(huì)走索引，而2525/19714=13%的情況下，會(huì)全表掃描。
也就是說(shuō)當(dāng)是datetime類型時(shí)，查詢結(jié)果占13%的情況下，會(huì)走索引查詢，而當(dāng)是varchar類型時(shí)，查詢結(jié)果占全表數(shù)據(jù)的13%時(shí)，會(huì)走全表掃描。這也是為什么日期類型我們要設(shè)置為datetime而不是varchar的原因之一。

總結(jié)

通過(guò)上述分析，可以總結(jié)如下結(jié)論:
1.范圍查詢中，當(dāng)查詢的數(shù)據(jù)量達(dá)到一定范圍后，mysql認(rèn)為全表掃描效率更高，會(huì)走全表掃描，而非索引。
2.datetime字段類型的值在查詢時(shí)也要加引號(hào)，否則mysql不會(huì)按日期進(jìn)行處理。
3.日期格式的數(shù)據(jù)，設(shè)置為varchar類型，范圍查詢走索引還是全表掃描的臨界值比datetime類型的查詢走索引查詢還是全表掃描的臨界值低，所以日期類型數(shù)據(jù)設(shè)置為datetime類型，會(huì)有更高概率走索引查詢。

到此這篇關(guān)于記一次Mysql不走日期字段索引的原因的文章就介紹到這了,更多相關(guān)Mysql 日期字段索引內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論