前面一篇文章，松哥和大家聊了 MySQL 中的索引合并，雖然 MySQL 提供了索引合并機(jī)制來提升 SQL 執(zhí)行的效率，然而在具體實(shí)踐中，如果能避免發(fā)生索引合并是最好的，畢竟這是沒辦法的辦法，是一個下下策。發(fā)生索引合并大概率是因為我們索引在設(shè)計的時候就有問題，設(shè)計好聯(lián)合索引，我們就能在一定程度上避免發(fā)生索引合并問題。

1. 聯(lián)合索引

1.1 什么是聯(lián)合索引

聯(lián)合索引就是數(shù)據(jù)表中的多個字段，共同組成一個索引。由于 InnoDB 中索引的數(shù)據(jù)結(jié)構(gòu)是一個 B+Tree，當(dāng)是一個聯(lián)合索引的時候，排序的時候會首先按照聯(lián)合索引的第一個字段排序，如果第一個字段的值相同，則按照第二個字段排序，如果第二個字段的值也相同，則按照第三個字段排序，以此類推。

舉一個簡單的例子，假設(shè)我有如下數(shù)據(jù)：

現(xiàn)在我給 username 和 age 字段建立聯(lián)合索引，那么 B+Tree 在排序的時候，會首先按照 username 排序，當(dāng) username 相同的時候，再按照 age 進(jìn)行排序。畫出來的 B+Tree 如下圖：

如上圖，bw 相同的時候，按照 age 進(jìn)行排序。

如果我們想要在 MySQL 中，讓聯(lián)合索引發(fā)揮最大作用，就要充分考慮到聯(lián)合索引中各字段的順序。

1.2 聯(lián)合索引順序要考慮哪些因素？

在設(shè)計聯(lián)合索引的時候，我們最容易想到的原則是查詢條件影響了聯(lián)合索引中各個字段的順序，要根據(jù)查詢條件來設(shè)計聯(lián)合索引中各個字段的順序。

實(shí)際上，除了上面提到的查詢條件之外，聯(lián)合索引的順序還會影響到查詢的排序和分組等，所以，設(shè)計聯(lián)合索引的順序可以算是一個真真正正的技術(shù)活。

2. 案例分析

松哥這里還是使用官方的案例吧，小伙伴們在公眾號后臺回復(fù) mysql官方案例 可以獲取到這個數(shù)據(jù)庫腳本的下載地址。

在 MySQL 的官方案例中，有一個支付表 payment，如下圖：

小伙伴們從圖中可以看到，這個表中有一個 customer_id 和一個 staff_id，現(xiàn)在假設(shè)我想要按照這兩個來進(jìn)行搜索，例如執(zhí)行如下 SQL：

select * from payment where customer_id=1 and staff_id=2;

查詢條件有兩個，我想建立一個聯(lián)合索引，那么究竟是把 customer_id 放在前面還是把 staff_id 放在前面呢？

一個比較常用的法則是看字段的選擇性，選擇性高的字段應(yīng)該是放在前面。有的小伙伴可能還不清楚什么是字段的選擇性，可以參考松哥之前的文章：前綴索引，在性能和空間中尋找平衡。

那么怎么獲取各個字段的選擇性呢？這個很好計算，一個 SQL 搞定，如下：

select count(distinct customer_id)/count(1) as c,count(distinct staff_id)/count(1) as s from payment;

執(zhí)行結(jié)果如下：

可以看到，customer_id 的選擇性為 0.0373，而 staff_id 的選擇性為 0.0001，那么在建立聯(lián)合索引的時候，將 customer_id 放在第一列顯然更合適一些，因為它的選擇性更高（意味著字段里邊重復(fù)的值相對來說會少一些），根據(jù) customer_id 更容易鎖定一行，查詢效率要更高一些。

不過需要注意，上面的法則并非放之四海而皆準(zhǔn)，還是要具體問題具體分析。在一些特別極端的情況下，索引選擇性非常之低，那個時候就沒有必要建立聯(lián)合索引了。特殊情況甚至需要我們從業(yè)務(wù)邏輯上去解決。

松哥舉一個例子來說明這個問題。

在我第一版的 vhr 中，當(dāng)時有一個系統(tǒng)通知的功能，就是管理員可以給所有的用戶群發(fā)消息。用戶之間也可以互發(fā)消息，如果發(fā)送消息的時候，用戶不在線，就需要先把消息存到數(shù)據(jù)庫中，等用戶上線了再推給用戶，那么就需要一張表來保存消息。這個表中有一個字段就是消息發(fā)送者，由于網(wǎng)站經(jīng)常需要發(fā)送通知，就導(dǎo)致這個字段的值分布非常不均，大約有 50% 的值都是 admin，剩下的 50% 則是其他普通用戶，那么查詢的時候，據(jù)此字段建立的聯(lián)合索引，如果查詢條件不是 admin，則過濾效果不錯，如果查詢條件是 admin，則過濾效果就非常差。對于這樣的問題，我們就需要從業(yè)務(wù)上去解決，例如禁止根據(jù) admin 去查詢等等。總之，建立聯(lián)合索引時，我們前面所所說的字段選擇性最高的原則，并不是放之四海而皆準(zhǔn)的，小伙伴們還是要具體情況具體分析。

3. 注意事項

由于聯(lián)合索引也是存儲在 B+Tree 中，如 1.1 小節(jié)圖示，username 在整棵 B+Tree 中是有序的，但是從整體上來看，age 是無序的，所以對于聯(lián)合索引在搜索的時候，需要滿足最做匹配原則才是有效的，否則會失效。舉例來說，如果查詢條件里只有 age，則索引就會失效，因為順著索引的 B+Tree 去查詢滿足條件的記錄，得一個一個找，還不如直接遍歷主鍵索引。