MySQL查詢?nèi)哂嗨饕臀词褂眠^的索引操作

更新時(shí)間：2021年03月30日 09:22:59 作者：遺失的曾經(jīng)！

這篇文章主要介紹了MySQL查詢?nèi)哂嗨饕臀词褂眠^的索引操作，具有很好的參考價(jià)值，希望對(duì)大家有所幫助。一起跟隨小編過來看看吧

MySQL5.7及以上版本提供直接查詢?nèi)哂嗨饕?、重?fù)索引和未使用過索引的視圖，直接查詢即可。

查詢?nèi)哂嗨饕?、重?fù)索引

select * sys.from schema_redundant_indexes;

查詢未使用過的索引

select * from sys.schema_unused_indexes;

如果想在5.6和5.5版本使用，將視圖轉(zhuǎn)換成SQL語(yǔ)句查詢即可

查詢?nèi)哂嗨饕?、重?fù)索引

select a.`table_schema`,a.`table_name`,a.`index_name`,a.`index_columns`,b.`index_name`,b.`index_columns`,concat('ALTER TABLE `',a.`table_schema`,'`.`',a.`table_name`,'` DROP INDEX `',a.`index_name`,'`') from ((select `information_schema`.`statistics`.`TABLE_SCHEMA` AS `table_schema`,`information_schema`.`statistics`.`TABLE_NAME` AS `table_name`,`information_schema`.`statistics`.`INDEX_NAME` AS `index_name`,max(`information_schema`.`statistics`.`NON_UNIQUE`) AS `non_unique`,max(if(isnull(`information_schema`.`statistics`.`SUB_PART`),0,1)) AS `subpart_exists`,group_concat(`information_schema`.`statistics`.`COLUMN_NAME` order by `information_schema`.`statistics`.`SEQ_IN_INDEX` ASC separator ',') AS `index_columns` from `information_schema`.`statistics` where ((`information_schema`.`statistics`.`INDEX_TYPE` = 'BTREE') and (`information_schema`.`statistics`.`TABLE_SCHEMA` not in ('mysql','sys','INFORMATION_SCHEMA','PERFORMANCE_SCHEMA'))) group by `information_schema`.`statistics`.`TABLE_SCHEMA`,`information_schema`.`statistics`.`TABLE_NAME`,`information_schema`.`statistics`.`INDEX_NAME`) a join (select `information_schema`.`statistics`.`TABLE_SCHEMA` AS `table_schema`,`information_schema`.`statistics`.`TABLE_NAME` AS `table_name`,`information_schema`.`statistics`.`INDEX_NAME` AS `index_name`,max(`information_schema`.`statistics`.`NON_UNIQUE`) AS `non_unique`,max(if(isnull(`information_schema`.`statistics`.`SUB_PART`),0,1)) AS `subpart_exists`,group_concat(`information_schema`.`statistics`.`COLUMN_NAME` order by `information_schema`.`statistics`.`SEQ_IN_INDEX` ASC separator ',') AS `index_columns` from `information_schema`.`statistics` where ((`information_schema`.`statistics`.`INDEX_TYPE` = 'BTREE') and (`information_schema`.`statistics`.`TABLE_SCHEMA` not in ('mysql','sys','INFORMATION_SCHEMA','PERFORMANCE_SCHEMA'))) group by `information_schema`.`statistics`.`TABLE_SCHEMA`,`information_schema`.`statistics`.`TABLE_NAME`,`information_schema`.`statistics`.`INDEX_NAME`) b on(((a.`table_schema` = b.`table_schema`) and (a.`table_name` = b.`table_name`)))) where ((a.`index_name` <> b.`index_name`) and (((a.`index_columns` = b.`index_columns`) and ((a.`non_unique` > b.`non_unique`) or ((a.`non_unique` = b.`non_unique`) and (if((a.`index_name` = 'PRIMARY'),'',a.`index_name`) > if((b.`index_name` = 'PRIMARY'),'',b.`index_name`))))) or ((locate(concat(a.`index_columns`,','),b.`index_columns`) = 1) and (a.`non_unique` = 1)) or ((locate(concat(b.`index_columns`,','),a.`index_columns`) = 1) and (b.`non_unique` = 0))));

查詢未使用過的索引

select `information_schema`.`statistics`.`TABLE_SCHEMA` AS `table_schema`,`information_schema`.`statistics`.`TABLE_NAME` AS `table_name`,`information_schema`.`statistics`.`INDEX_NAME` AS `index_name`,max(`information_schema`.`statistics`.`NON_UNIQUE`) AS `non_unique`,max(if(isnull(`information_schema`.`statistics`.`SUB_PART`),0,1)) AS `subpart_exists`,group_concat(`information_schema`.`statistics`.`COLUMN_NAME` order by `information_schema`.`statistics`.`SEQ_IN_INDEX` ASC separator ',') AS `index_columns` from `information_schema`.`statistics` where ((`information_schema`.`statistics`.`INDEX_TYPE` = 'BTREE') and (`information_schema`.`statistics`.`TABLE_SCHEMA` not in ('mysql','sys','INFORMATION_SCHEMA','PERFORMANCE_SCHEMA'))) group by `information_schema`.`statistics`.`TABLE_SCHEMA`,`information_schema`.`statistics`.`TABLE_NAME`,`information_schema`.`statistics`.`INDEX_NAME`

補(bǔ)充：mysql ID 取余索引_mysql重復(fù)索引、冗余索引、未使用索引的定義和查找

1.冗余和重復(fù)索引

mysql允許在相同列上創(chuàng)建多個(gè)索引，無論是有意還是無意，mysql需要單獨(dú)維護(hù)重復(fù)的索引，并且優(yōu)化器在優(yōu)化查詢的時(shí)候也需要逐個(gè)地進(jìn)行考慮，這會(huì)影響性能。重復(fù)索引是指的在相同的列上按照相同的順序創(chuàng)建的相同類型的索引，應(yīng)該避免這樣創(chuàng)建重復(fù)所以，發(fā)現(xiàn)以后也應(yīng)該立即刪除。但，在相同的列上創(chuàng)建不同類型的索引來滿足不同的查詢需求是可以的。

冗余索引和重復(fù)索引有一些不同，如果創(chuàng)建了索引(a,b)，再創(chuàng)建索引(a)就是冗余索引，因?yàn)檫@只是前面一個(gè)索引的前綴索引，因此(a,b)也可以當(dāng)作(a)來使用，但是(b,a)就不是冗余索引，索引(b)也不是，因?yàn)閎不是索引(a,b)的最左前綴列，另外，其他不同類型的索引在相同列上創(chuàng)建(如哈希索引和全文索引)不會(huì)是btree索引的冗余索引。

另外：對(duì)于二級(jí)索引(a,id)，id是主鍵，對(duì)于innodb來說，主鍵列已經(jīng)包含在二級(jí)索引中了，所以這個(gè)也是冗余索引。大多數(shù)情況下都不需要冗余索引，應(yīng)該盡量擴(kuò)展已有的索引而不是創(chuàng)建新索引，但也有時(shí)候處于性能方面的考慮需要冗余索引，因?yàn)閿U(kuò)展已有的索引會(huì)導(dǎo)致其變得太大，從而影響其他使用該索引的查詢性能。如：如果在整數(shù)列上有一個(gè)索引，現(xiàn)在需要額外增加一個(gè)很長(zhǎng)的varchar列來擴(kuò)展該索引，那么性可能會(huì)急劇下降，特別是有查詢把這個(gè)索引當(dāng)作覆蓋索引，或者這是myisam表并且有很多范圍查詢的時(shí)候(由于myisam的前綴壓縮)。

如：表userinfo，myisam引擎，有100W行記錄，每個(gè)state_id值大概2W行，在state_id列有一個(gè)索引對(duì)下面的查詢有用：如：select count(*) from userinfo where state_id=5;測(cè)試每秒115次QPS

對(duì)于下面的查詢這個(gè)state_id列的索引就不太頂用了，每秒QPS是10次

select state_id,city,address from userinfo where state_id=5;

如果把state_id索引擴(kuò)展為(state_id,city,address)，那么第二個(gè)查詢的性能更快了，但是第一個(gè)查詢卻變慢了，如果要兩個(gè)查詢都快，那么就必須要把state_id列索引進(jìn)行冗余了。但如果是innodb表，不冗余state_id列索引對(duì)第一個(gè)查詢的影響并不明顯，因?yàn)閕nnodb沒有使用索引壓縮，myisam和innmodb表使用不同的索引策略的select查詢的qps測(cè)試結(jié)果(以下測(cè)試數(shù)據(jù)僅供參考)：

只有state_id列索引只有state_id_2索引同時(shí)有兩個(gè)索引

myisam,第一個(gè)查詢 114.96 25.40 112.19

myisam,第二個(gè)查詢 9.97 16.34 16.37

innodb,第一個(gè)查詢 108.55 100.33 107.97

innodb,第二個(gè)查詢 12.12 28.04 28.06

從上圖中可以看出，兩個(gè)索引都有的時(shí)候，缺點(diǎn)是成本更高，下面是在不同的索引策略時(shí)插入innodb和myisam表100W行數(shù)據(jù)的速度(以下測(cè)試數(shù)據(jù)僅供參考)：

只有state_id列索引同時(shí)有兩個(gè)索引

innodb,對(duì)有兩個(gè)索引都有足夠的內(nèi)容的時(shí)候 80秒 136秒

myisam,只有一個(gè)索引有足夠的內(nèi)容的時(shí)候 72秒 470秒

可以看到，不論什么引擎，索引越多，插入速度越慢，特別是新增索引后導(dǎo)致達(dá)到了內(nèi)存瓶頸的時(shí)候。解決冗余索引和重復(fù)索引的方法很簡(jiǎn)單，刪除這些索引就可以了，但首先要做的是找出這樣的索引，可以通過一些復(fù)雜的訪問information_schema表的查詢來找，不過還有兩個(gè)更簡(jiǎn)單的方法，使用：shlomi noach的common_schema中的一些視圖來定位，也可以使用percona toolkit中的pt-dupulicate-key-checker工具，該工具通過分析表結(jié)構(gòu)來找出冗余和重復(fù)的索引，對(duì)于大型服務(wù)器來說，使用外部的工具更合適，如果服務(wù)器上有大量的數(shù)據(jù)或者大量的表，查詢information_schema表可能會(huì)導(dǎo)致性能問題。建議使用pt-dupulicate-key-checker工具。

在刪除索引的時(shí)候要非常小心：

如果在innodb引擎表上有where a=5 order by id這樣的查詢，那么索引(a)就會(huì)很有用，索引(a,b)實(shí)際上是(a,b,id)索引，這個(gè)索引對(duì)于where a=5 order by id這樣的查詢就無法使用索引做排序，而只能使用文件排序了。所以，建議使用percona工具箱中的pt-upgrade工具來仔細(xì)檢查計(jì)劃中的索引變更。

2. 未使用的索引

除了冗余索引和重復(fù)索引，可能還會(huì)有一些服務(wù)器永遠(yuǎn)不使用的索引，這樣的索引完全是累贅，建議考慮刪除，有兩個(gè)工具可以幫助定位未使用的索引：

A：在percona server或者mariadb中先打開userstat=ON服務(wù)器變量，默認(rèn)是關(guān)閉的，然后讓服務(wù)器運(yùn)行一段時(shí)間，再通過查詢information_schema.index_statistics就能查到每個(gè)索引的使用頻率。

B：使用percona toolkit中的pt-index-usage工具，該工具可以讀取查詢?nèi)罩荆?duì)日志中的每個(gè)查詢進(jìn)行explain操作，然后打印出關(guān)羽索引和查詢的報(bào)告，這個(gè)工具不僅可以找出哪些索引是未使用的，還可以了解查詢的執(zhí)行計(jì)劃，如：在某些情況下有些類似的查詢的執(zhí)行方式不一樣，這可以幫助定位到那些偶爾服務(wù)器質(zhì)量差的查詢，該工具也可以將結(jié)果寫入到mysql的表中，方便查詢結(jié)果。

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。如有錯(cuò)誤或未考慮完全的地方，望不吝賜教。

您可能感興趣的文章: