InnoDB索引

索引构造如上图：

• 行记录单独存储;
• id为PK，有一棵id的索引树，叶子指向行记录;
• name为KEY，有一棵name的索引树，叶子也指向行记录;

问题2：InnoDB的索引结构是怎样的?

InnoDB的主键索引与行记录是存储在一起的，故叫做聚集索引(Clustered Index)：

• 没有单独区域存储行记录;
• 主键索引的叶子节点，存储主键，与对应行记录(而不是指针);

画外音：因此，InnoDB的PK查询是非常快的。

因为这个特性，InnoDB的表必须要有聚集索引：

• 如果表定义了PK，则PK就是聚集索引;
• 如果表没有定义PK，则第一个非空unique列是聚集索引;
• 否则，InnoDB会创建一个隐藏的row-id作为聚集索引;

聚集索引，也只能够有一个，因为行数据在物理磁盘上只能有一份聚集存noDB的普通索引可以有多个，它与聚集索引是不同的：普通索引的叶子节点，存储主键(也不是指针);

问题3：InnoDB为何建议使用趋势递增主键?

InnoDB由于数据行与索引一体，如果使用趋势递增主键，插入记录时，不会索引分裂，不会大量行记录移动。

问题4：InnoDB为何不宜使用较长的列做主键?

假设有一个用户中心场景，包含身份证号，身份证MD5，姓名，出生年月等业务属性，这些属性上均有查询需求，并且有事务需求，必须使用InnoDB存储引擎。

此时，如何来设计数据表呢?

最容易想到的设计方式是：的索引树与行记录结构如上：

• id_code聚集索引，关联行记录;
• 其他索引，存储id_code属性值;

身份证号id_code是一个比较长的字符串，每个索引都存储这个值，在数据量大，内存珍贵的情况下，MySQL有限的缓冲区，存储的索引与数据会减少，磁盘IO的概率会增加。

画外音：同时，索引占用的磁盘空间也会增加。

此时，应该新增一个无业务含义的id自增列：

• 以id自增列为聚集索引，关联行记录;
• 其他索引，存储id值;一来，有限的缓冲区，能够缓冲更多的索引与行数据，磁盘IO的频率会降低，整体性能会增加。

  InnoDB为何不宜使用较长的列作为主键，这下懂了吧?

  问题5：InnoDB的普通索引存储主键键值，可能存在什么问题?

  使用普通索引查询时，可能出现回表查询。

  什么是回表查询?
  

（编辑：桂林站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!