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

这篇文章主要介绍 InnoDB 表为什么一定要用自增列做主键，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！

0、导读

我们先了解下 InnoDB 引擎表的一些关键特征：

InnoDB 引擎表是基于 B + 树的索引组织表(IOT)；

每个表都需要有一个聚集索引(clustered index)；

所有的行记录都存储在 B + 树的叶子节点(leaf pages of the tree)；

基于聚集索引的增、删、改、查的效率相对是最高的；

如果我们定义了主键(PRIMARY KEY)，那么 InnoDB 会选择其作为聚集索引；

如果没有显式定义主键，则 InnoDB 会选择第一个不包含有 NULL 值的唯一索引作为主键索引；

如果也没有这样的唯一索引，则 InnoDB 会选择内置 6 字节长的 ROWID 作为隐含的聚集索引(ROWID 随着行记录的写入而主键递增，这个 ROWID 不像 ORACLE 的 ROWID 那样可引用，是隐含的)。

综上总结，如果 InnoDB 表的数据写入顺序能和 B + 树索引的叶子节点顺序一致的话，这时候存取效率是最高的，也就是下面这几种情况的存取效率最高：

使用自增列 (INT/BIGINT 类型) 做主键，这时候写入顺序是自增的，和 B + 数叶子节点分裂顺序一致；

该表不指定自增列做主键，同时也没有可以被选为主键的唯一索引(上面的条件)，这时候 InnoDB 会选择内置的 ROWID 作为主键，写入顺序和 ROWID 增长顺序一致；

除此以外，如果一个 InnoDB 表没有显式主键，但有可以被选择为主键的唯一索引，且该唯一索引可能不是递增关系时(例如字符串、UUID、多字段联合唯一索引的情况)，该表的存取效率就会特别差。

实际情况是如何呢？经过简单 TPCC 基准测试，修改为使用自增列作为主键与原始表结构分别进行 TPCC 测试，前者的 TpmC 结果比后者高 9% 倍，足见使用自增列做 InnoDB 表主键的明显好处，其他更多不同场景下使用自增列的性能提升可以自行对比测试下。

附图：

1、B+ 树典型结构

2、InnoDB 主键逻辑结构

以上是“InnoDB 表为什么一定要用自增列做主键”这篇文章的所有内容，感谢各位的阅读！希望分享的内容对大家有帮助，更多相关知识，欢迎关注丸趣 TV 行业资讯频道！