新特性解讀 | MySQL 8.0 索引特性3 -倒序索引

原創做者： 楊濤濤

---

咱們今天來介紹下 MySQL 8.0 引入的新特性：倒序索引。

 

MySQL長期以來對索引的創建只容許正向asc存儲，就算創建了desc，也是忽略掉。

好比對於如下的查詢，沒法發揮索引的最佳性能。

• 查詢一：

select * from tb1 where f1 = ... order by id desc;

• 查詢二：

select * from tb1 where f1 = ... order by f1 asc , f2 desc;

 

那對於上面的查詢，尤爲是數據量和併發到必定峯值的時候，則對OS的資源消耗很是大。通常這樣的SQL在查詢計劃裏面會出現using filesort等狀態。

好比針對下面的表t1，針對字段rank1有兩個索引，一個是正序的，一個是反序的。不過在MySQL 8.0 以前的版本都是按照正序來存儲。

 

按照rank1 正向排序的執行計劃，

 

按照rank1 反向排序的執行計劃，

 

從執行計劃來看，反向比正向除了extra裏多了Using temporary; Using filesort這兩個，其餘的如出一轍。這兩個就表明中間用到了臨時表和排序，通常來講，凡是執行計劃裏用到了這兩個的，性能幾乎都不咋地。除非我這個臨時表不太大，而用於排序的buffer也足夠大，那性能也不至於太差。那這兩個選項到底對性能有多大影響呢？

咱們分別執行這兩個查詢，而且查看MySQL的session級的status就大概能看出些許不一樣。

經過以上兩張圖，咱們發現反向的比正向的多了不少個計數，好比經過掃描的記錄數增長了10倍，並且還伴有10倍的臨時表的讀和寫記錄數。那這個開銷是很是巨大的。那以上的查詢是在MySQL 5.7 上運行的。

 

MySQL 8.0 給咱們帶來了倒序索引（Descending Indexes），也就是說反向存儲的索引。 這裏不要跟搜索引擎中的倒排索引混淆了，MySQL這裏只是反向排序存儲而已。不過這個倒序存儲已經解決了很大的問題。咱們再看下以前在MySQL 5.7 上運行的例子。

咱們把數據導入到MySQL 8.0，

再把原來的索引變爲倒序索引，

再次看下第二個SQL的查詢計劃，

很顯然，用到了這個倒序索引 idx_rank1_desc，而這裏的臨時表等的信息消失了。

 

固然了，這裏的組合比較多，好比我這張表的字段rank1,rank2兩個能夠任意組合。

• 組合一：

(rank1 asc,rank2 asc);

• 組合二：

(rank1 desc,rank2 desc);

• 組合三：

(rank1 asc,rank2 desc);

• 組合四：

(rank1 desc,rank2 asc);

 

我把這幾個加上，適合的查詢好比：

• 查詢一：

Select * from t1 where rank1 = 11 order by rank2;

• 查詢二：

Select * from t1 where 1 order by rank1,rank2;

• 查詢三：

Select * from t1 where 1 order by rank1 desc,rank2;

...

等等，這裏就不一一示範了。