mysql關于主鍵索引的分析

本篇內容介紹了“mysql關于主鍵索引的分析”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

到底InnoDB會不會在索引末尾加上主鍵，什么時候會加？

CREATE TABLE t ( a char(32) not null primary key, b char(32) not null, KEY idx1 (a,b), KEY idx2 (b,a) ) Engine=InnoDB;

插入部分數據后可以看到idx1和idx2兩個索引的大小相同。這說明idx1和idx2的內部結構是一樣的，因此 不可能 是idx1在內部存為(a,b,a)。

只要用戶定義的索引字段中包含了主鍵中的字段，那么這個字段就不會再被InnoDB自動加到索引中了，如果用戶的索引字段中沒有完全包含主鍵字段，InnoDB就會把剩下的主鍵字段加到索引末尾。

因此我們最初的例子中， idx1 和 idx2 兩個索引內部大小完全一樣，沒有區別。

最后再補充下組合主鍵的例子：

CREATE TABLE t ( a char(32) not null, b char(32) not null, c char(32) not null, d char(32) not null, PRIMARY KEY (a,b) KEY idx1 (c,a), KEY idx2 (d,b) ) Engine=InnoDB;

這個表InnoDB會自動補全主鍵字典，idx1 實際上內部存儲為 (c,a,b)，idx2 實際上內部存儲為 (d,b,a)。
但是這個自動添加的字段，Server層是不知道的，所以MySQL優化器并不知道這個字段的存在，所以如果你有一個查詢：

SELECT * FROM t WHERE d=x1 AND b=x2 ORDER BY a;

其實內部存儲的idx2(d,b,a)可以讓這個查詢完全走索引，但是由于Server層不知道，所以最終MySQL優化器可能選擇 idx2(d,b) 做過濾然后排序 a 字段，或者直接用PK掃描避免排序。

而如果我們定義表結構的時候就定義為 KEY idx2(d,b,a) ，那么MySQL就知道(d,b,a)三個字段索引中都有，并且InnoDB發現用戶定義的索引中包含了所有的主鍵字段，也不會再添加了，并沒有增加存儲空間。

因此，由衷的建議，所有的DBA建索引的時候，都在業務要求的索引字段后面補上主鍵字段，這沒有任何損失，但是可能給你帶來意外的驚喜。

“mysql關于主鍵索引的分析”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！