共计 1143 个字符，预计需要花费 3 分钟才能阅读完成。

本篇内容介绍了“mysql 关于主键索引的分析”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让丸趣 TV 小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

到底 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 关于主键索引的分析”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注丸趣 TV 网站，丸趣 TV 小编将为大家输出更多高质量的实用文章！