共計 1143 個字符，預計需要花費 3 分鐘才能閱讀完成。

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

到底 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;

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

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

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

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

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 實際上內(nèi)部存儲為 (c,a,b)，idx2 實際上內(nèi)部存儲為 (d,b,a)。
但是這個自動添加的字段，Server 層是不知道的，所以 MySQL 優(yōu)化器并不知道這個字段的存在，所以如果你有一個查詢：

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

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

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

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

“mysql 關于主鍵索引的分析”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注丸趣 TV 網(wǎng)站，丸趣 TV 小編將為大家輸出更多高質(zhì)量的實用文章！