ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花

MySQL 中索引与数据的存储位置，核心取决于所使用的存储引擎，其中 InnoDB 作为当前 MySQL 默认存储引擎，其索引与数据采用“索引组织表（IOT）”模式实现一体化存储，索引即是数据的组织载体，数据的存储位置与索引结构深度绑定；而 MyISAM 引擎采用“非索引组织表”模式，索引与数据分开存储，二者存储位置相互独立。本文重点围绕 InnoDB 引擎，详细解析索引与数据的存储位置、层级分布及关联机制，同时简要对比 MyISAM 引擎差异，确保内容的专业性与严谨性。

一、InnoDB 引擎核心存储原则：索引与数据一体化存储

InnoDB 引擎的核心设计理念是“索引组织表（Index-Organized Table, IOT）”，即数据表的全部行数据均以聚簇索引 B+ 树为核心进行组织存储，聚簇索引的叶子节点直接存储完整行数据，二级索引作为辅助索引，仅存储索引键值与聚簇索引主键值，不存储完整数据。索引与数据的存储位置均位于 InnoDB 表空间中，遵循“表空间→段→区→页→行”的五级逻辑分层结构，二者共享存储资源但各有独立的段分配。

核心结论：InnoDB 中，聚簇索引与数据存储于同一表空间的同一数据段，二级索引存储于同一表空间的独立索引段；无独立索引文件，所有索引与数据均封装在表空间文件（.ibd 或 ibdata1）中，实现索引与数据的一体化管理。

二、数据存储位置详解（InnoDB 引擎）

InnoDB 数据的存储位置贯穿五级逻辑分层结构，从顶层表空间到底层行单元，层层嵌套，数据的物理存储与逻辑组织高度统一，具体存储位置及特征如下：

1. 顶层存储：表空间（Tablespace）

表空间是 InnoDB 数据（含索引）的最高级存储容器，所有数据与索引均存储于表空间内，不同类型表空间的存储位置与管理方式不同，直接决定数据的物理存储路径：

• 独立表空间：开启innodb_file_per_table 参数后生效（MySQL 5.6 及以上默认开启），每张表对应独立的表空间文件 [表名].ibd，存储该表的全部数据（聚簇索引叶子节点）与所有索引（聚簇索引、二级索引），物理存储路径与数据表所在数据库目录一致。
• 系统表空间：默认文件为 ibdata1（可通过 innodb_data_file_path 配置多文件），存储未开启独立表空间的表数据与索引、数据字典、双写缓冲、回滚段、undo 日志等核心内容，物理存储路径为 MySQL 数据目录，所有共享该表空间的表，其数据与索引均存储于该文件中。
• 通用表空间：手动创建的共享表空间，文件名为 [表空间名].ibd，可存储多张表的 data 与索引，物理存储路径可自定义，兼顾独立表空间的灵活管理与系统表空间的资源共享优势。
• 临时表空间：默认文件为 ibtmp1，存储会话级临时表的数据与索引，物理存储路径为 MySQL 数据目录，会话结束或数据库重启后自动清理，不具备数据持久化能力。

2. 中层存储：段（Segment）、区（Extent）、页（Page）

表空间内部通过段、区、页实现数据的分层聚合管理，数据的实际存储载体为页，段与区用于优化空间分配与 I/O 效率，具体关联如下：

• 段（Segment）：数据的逻辑分配单元，InnoDB 为聚簇索引分配独立的数据段（存储行数据），为每一个二级索引分配独立的索引段（存储二级索引数据）。数据段与索引段均属于表空间的子单元，共享表空间的存储资源，其存储位置随表空间类型而定。
• 区（Extent）：段的组成单元，默认大小 1MB（对应 64 个 16KB 页），用于解决单页频繁分配的效率瓶颈。数据段与索引段均由若干连续或零散的区组成，新创建的段初始分配 32 个零散页（初始区），数据量达到阈值后以完整区为单位分配，区的连续性确保数据与索引的高效 I/O。
• 页（Page）：InnoDB 磁盘 I/O 的最小单元，默认大小 16KB（可通过 innodb_page_size 配置），是数据与索引的实际存储载体。数据主要存储于数据页（INDEX 类型）中，每一个数据页对应聚簇索引 B+ 树的一个节点，叶子节点存储完整行数据，非叶子节点存储索引导航信息；索引（含二级索引）同样存储于对应类型的页中（如索引页），与数据页共享区的存储资源。

3. 底层存储：行（Row）

行是数据的最小逻辑单元，存储于数据页的用户记录（User Records）区域，每一行数据均包含事务与 MVCC 所需的隐藏列（DB_TRX_ID、DB_ROLL_PTR、DB_ROW_ID），其存储位置严格遵循聚簇索引主键顺序，与聚簇索引叶子节点的存储顺序完全一致。行数据的物理存储位置由其所在的数据页决定，而数据页的位置由区、段、表空间层层定位，最终映射到具体的磁盘文件。

三、索引存储位置详解（InnoDB 引擎）

InnoDB 索引分为聚簇索引与二级索引，二者存储位置均位于表空间内，但分属不同的段，存储结构与关联方式存在显著差异，具体如下：

1. 聚簇索引（Clustered Index）：与数据同存储

聚簇索引是 InnoDB 索引组织表的核心，其存储位置与数据完全融合，核心特征如下：

• 存储位置：与表数据存储于同一数据段，位于对应表空间的 data 区域，其 B+ 树的叶子节点直接存储完整行数据，非叶子节点存储主键值与子节点指针，无需额外占用独立存储空间。
• 存储关联：聚簇索引的构建与数据存储同步完成，主键顺序决定数据的存储顺序，数据的物理存储位置与聚簇索引的逻辑顺序高度一致，实现“索引即数据，数据即索引”的一体化存储。
• 位置定位：聚簇索引的根页位置固定存储于表空间的特定区域，通过根页可逐层定位到所有叶子节点（行数据），其存储路径为：表空间→数据段→区→数据页→聚簇索引节点（叶子节点为行数据）。

2. 二级索引（Secondary Index）：独立存储，关联聚簇索引

二级索引作为辅助索引，用于优化非主键查询，其存储位置独立于数据，但需通过主键值与聚簇索引关联，核心特征如下：

• 存储位置：每一个二级索引对应一个独立的索引段，位于同一表空间内（与数据段共享表空间资源），但与数据段相互独立，不存储完整行数据，仅存储二级索引键值与对应的主键值。
• 存储结构：二级索引同样以 B+ 树形式存储，其叶子节点存储“二级索引键值 + 主键值”，非叶子节点存储二级索引键值与子节点指针；所有二级索引的 B+ 树均独立存在，其存储路径为：表空间→索引段→区→索引页→二级索引节点。
• 与数据的关联：二级索引不直接关联行数据，需通过叶子节点存储的主键值，回查聚簇索引获取完整行数据（即回表机制）；若查询字段仅包含二级索引键值与主键值（覆盖索引场景），可直接从二级索引获取数据，无需回查聚簇索引。

四、InnoDB 与 MyISAM 引擎：索引与数据存储位置差异

为进一步明确 InnoDB 索引与数据的存储特性，此处简要对比 MyISAM 引擎的存储模式，突出二者核心差异，避免混淆：

五、核心总结

MySQL 索引与数据的存储位置，核心由存储引擎决定，InnoDB 引擎作为企业级应用的主流选择，其索引与数据采用一体化存储模式，核心要点可归纳为：

1. 存储载体：所有索引与数据均存储于表空间（.ibd 或 ibdata1），无独立索引文件，实现统一管理；
2. 聚簇索引：与数据同段存储，叶子节点直接存储行数据，是数据组织的核心，其存储位置与数据完全融合；
3. 二级索引：独立索引段存储，仅存储索引键值与主键值，通过回表机制关联聚簇索引获取数据；
4. 层级关联：索引与数据的存储均遵循“表空间→段→区→页→行”的五级结构，物理位置与逻辑结构高度统一。

该存储设计既保障了事务 ACID 特性的实现，又通过索引与数据的一体化组织，减少磁盘 I/O 开销，提升查询效率，是 InnoDB 引擎适配高并发、强事务、大数据量场景的核心优势之一。

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花