“InnoDB：InnoDB 磁盘结构：Indexes”的版本间差异
跳到导航
跳到搜索
（建立内容为“category:MySQL == 聚集索引和二级索引 == == InnoDB 索引的物理结构 == == 排序索引版本 == == InnoDB FULLTEXT 索引 ==”的新页面） |
|||
| 第1行： | 第1行： | ||
[[category:MySQL]] | [[category:MySQL]] | ||
== | == 聚集索引和二级索引【！！！】 == | ||
每个 InnoDB 表都有一个称为“'''clustered index'''”的特殊索引，其中存储了行数据。<big>'''通常，聚集索引与 primary key 同义'''</big>。 | |||
# 在表上定义“PRIMARY KEY”时，InnoDB 会将其用作聚集索引。为您创建的每个表定义一个主键。如果没有逻辑唯一且非空的列或列集，请添加一个新的“auto-increment”列，其值将自动填写。 | |||
# 如果您没有为表定义“PRIMARY KEY”，则 MySQL 将找到'''第一个'''“UNIQUE”索引，其中所有键列均为“NOT NULL”，而 InnoDB 将其用作聚集索引。 | |||
# 如果表没有“PRIMARY KEY”或合适的“UNIQUE”索引，则 InnoDB 在包含行 ID 值的合成列上内部生成名为“'''GEN_CLUST_INDEX'''”的'''隐藏聚集索引'''。这些行由 InnoDB 分配给该表中的行的 ID 排序。行 ID 是一个 '''6''' 字节的字段，随着插入新行而单调增加。因此，按行 ID 排序的行实际上在插入 Sequences 上。 | |||
=== 聚集索引如何加快查询速度 === | |||
通过聚集索引访问行是快速的，因为索引搜索直接导致包含所有行数据的页面。如果表很大，则与使用不同于索引记录的页面存储行数据的存储组织相比，聚集索引体系结构通常可以节省磁盘 I/O 操作。 | |||
=== 二级索引如何与聚集索引相关 === | |||
<big>'''除聚集索引以外的所有索引'''都称为“'''secondary indexes'''”</big>（二级索引、第二索引、辅助索引）。在 InnoDB 中，'''辅助索引中的每个记录都包含该行的主键列以及为该辅助索引指定的列'''。 InnoDB 使用此主键值在聚集索引中搜索行。 | |||
* 如果主键较长，则辅助索引将使用更多空间，因此具有较短的主键是有利的。 | |||
== InnoDB 索引的物理结构 == | == InnoDB 索引的物理结构 == | ||
2021年4月18日 (日) 12:27的版本
聚集索引和二级索引【！！！】
每个 InnoDB 表都有一个称为“clustered index”的特殊索引，其中存储了行数据。通常，聚集索引与 primary key 同义。
- 在表上定义“PRIMARY KEY”时，InnoDB 会将其用作聚集索引。为您创建的每个表定义一个主键。如果没有逻辑唯一且非空的列或列集，请添加一个新的“auto-increment”列，其值将自动填写。
- 如果您没有为表定义“PRIMARY KEY”，则 MySQL 将找到第一个“UNIQUE”索引，其中所有键列均为“NOT NULL”，而 InnoDB 将其用作聚集索引。
- 如果表没有“PRIMARY KEY”或合适的“UNIQUE”索引，则 InnoDB 在包含行 ID 值的合成列上内部生成名为“GEN_CLUST_INDEX”的隐藏聚集索引。这些行由 InnoDB 分配给该表中的行的 ID 排序。行 ID 是一个 6 字节的字段，随着插入新行而单调增加。因此，按行 ID 排序的行实际上在插入 Sequences 上。
聚集索引如何加快查询速度
通过聚集索引访问行是快速的，因为索引搜索直接导致包含所有行数据的页面。如果表很大，则与使用不同于索引记录的页面存储行数据的存储组织相比，聚集索引体系结构通常可以节省磁盘 I/O 操作。
二级索引如何与聚集索引相关
除聚集索引以外的所有索引都称为“secondary indexes”（二级索引、第二索引、辅助索引）。在 InnoDB 中，辅助索引中的每个记录都包含该行的主键列以及为该辅助索引指定的列。 InnoDB 使用此主键值在聚集索引中搜索行。
- 如果主键较长，则辅助索引将使用更多空间，因此具有较短的主键是有利的。