mysqlunionall無法走索引

mysqlunionall無法走索引11 27

我們提供的服務(wù)有：網(wǎng)站設(shè)計(jì)、成都網(wǎng)站制作、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、壽縣ssl等。為近千家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的壽縣網(wǎng)站制作公司

1. like %%失效。 方案:改為like %,只寫后面的%就能走索引。

2. 雖然有索引,但是查詢條件沒有索引列或者order by 排序沒有索引列。 方案:讓查詢條件有索引列

3. 索引列存在null值的情況。 方案:索引列如果沒有值,則給空字符串或者數(shù)字的0,總之就是不要設(shè)置null

技術(shù)分享 | 為什么 SELECT 查詢選擇全表掃描，而不走索引？

SQL的執(zhí)行成本（cost）是 MySQL 優(yōu)化器選擇 SQL 執(zhí)行計(jì)劃時(shí)一個(gè)重要考量因素。當(dāng)優(yōu)化器認(rèn)為使用索引的成本高于全表掃描的時(shí)候，優(yōu)化器將會(huì)選擇全表掃描，而不是使用索引。

下面通過一個(gè)實(shí)驗(yàn)來說明。

如下結(jié)構(gòu)的一張表，表中約有104w行數(shù)據(jù)：

查詢1，并未用到ct_index(create_time)索引:

而查詢2，則用到了ct_index(create_time)索引:

這里使用optimizer trace工具，觀察MySQL對SQL的優(yōu)化處理過程：

獲得關(guān)于此SQL的詳細(xì)優(yōu)化器處理信息：

通過逐行閱讀，發(fā)現(xiàn)優(yōu)化器在join_optimization（SQL優(yōu)化階段）部分的rows_estimation內(nèi)容里：

通過觀察優(yōu)化器的信息，不難發(fā)現(xiàn)，使用索引掃描行數(shù)約52w行，而全表掃描約為104w行。為什么優(yōu)化器反而認(rèn)為使用索引的成本比全表掃描還高呢？

因?yàn)楫?dāng)ct_index(create_time)這個(gè)普通索引并不包括查詢的所有列，因此需要通過ct_index的索引樹找到對應(yīng)的主鍵id，然后再到id的索引樹進(jìn)行數(shù)據(jù)查詢，即回表（通過索引查出主鍵，再去查數(shù)據(jù)行），這樣成本必然上升。尤其是當(dāng)回表的數(shù)據(jù)量比較大的時(shí)候，經(jīng)常會(huì)出現(xiàn)MySQL優(yōu)化器認(rèn)為回表查詢代價(jià)過高而不選擇索引的情況。

這里可以回頭看查詢1 和 查詢2的數(shù)據(jù)量占比：

另外，在MySQL的官方文檔中對此也有簡要的描述：

參考文檔：

="或"'>MySQL使用">="或"

2020-02-27

最近一個(gè)日志頁面查詢很慢，然后去跟蹤了查詢sql，發(fā)現(xiàn)日期字段上即使建了索引，查詢還是很慢，執(zhí)行語句還是使用了全表掃描，于是繼續(xù)分析下去。

查詢語句類似:

select * from logs where createtime = '2020-01-01' ;

起初因?yàn)閐ate上沒檢索，查詢執(zhí)行的是全表掃描，給條件字段createtime建上索引：

再次執(zhí)行:

查詢執(zhí)行的還是全表掃描：

網(wǎng)上查詢有說是因?yàn)樵诓樵償?shù)據(jù)條數(shù)約占總條數(shù)五分之一以下時(shí)能夠使用到索引，但超過五分之一時(shí)，使用全表掃描。于是把日期范圍縮?。?/p>

果真，查詢執(zhí)行的是range：

由此可知，在進(jìn)行范圍查詢時(shí)，比如：、 、=、=等, 如果數(shù)據(jù)量過大的話，即使where條件字段已經(jīng)建立了索引，查詢語句執(zhí)行時(shí)還是有可能進(jìn)行全表掃描的。

實(shí)際上是不是全表的五分之一以下才會(huì)使用索引，這個(gè)不能確定，以后再研究了。

索引失效的情況有哪些

原因有如下：

1、最佳左前綴原則——如果索引了多列，要遵守最左前綴原則。指的是查詢要從索引的最左前列開始并且不跳過索引中的列。

2、不在索引列上做任何操作，會(huì)導(dǎo)致索引失效而導(dǎo)致全表掃描。

3、存儲(chǔ)引擎不能使用索引中范圍條件右邊的列，范圍之后索引失效。這寫條件判斷最后放到后面，先定位到小的范圍再開始。

4、mysql使用不等于(!= 或者)的時(shí)候，無法使用索引，會(huì)導(dǎo)致索引失效。

5、mysql中使用is not null 或者 is null會(huì)導(dǎo)致無法使用索引。

6、mysql中l(wèi)ike查詢是以%開頭，索引會(huì)失效變成全表掃描，覆蓋索引。

7、mysql中，如果條件中有or，即使其中有條件帶索引也不會(huì)使用(這也是為什么盡量少用or的原因)。要想使用or，又想讓索引生效，只能將or條件中的每個(gè)列都加上索引。

8、如果mysql使用全表掃描要比使用索引快,則不會(huì)使用到索引。

注意事項(xiàng)

1、索引列有函數(shù)處理或隱式轉(zhuǎn)換，不走索引。

2、索引列傾斜，個(gè)別值查詢時(shí)，走索引代價(jià)比走全表掃描高，所以不走索引。

3、索引列沒有限制 not null，索引不存儲(chǔ)空值，如果不限制索引列是not null，oracle會(huì)認(rèn)為索引列有可能存在空值，所以不會(huì)按照索引計(jì)算。