咱们先熟悉下InnoDB引擎表的一些关键特色：
InnoDB引擎表是基于B+树的索引布局表(IOT)；
每个表都须要有一个会合索引(clusteredindex)；
悉数的行纪录都储备在B+树的叶子节点(leafpagesofthetree)；
基于会合索引的增、删、改、查的效率相对是最高的；
倘若咱们界说了主键(PRIMARYKEY)，那末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主键逻辑构造
蔓延浏览：
1、TPCC-MySQL应用手册,