6.MySQL索引的数据结构【面试题】

B+ 树是 MySQL 中绝大多数索引的底层结构（如主键索引、普通索引、联合索引），它是一种平衡多路查找树，基于经典 B 树优化而来，专门为磁盘 IO 场景设计。

B+ 树的结构可概括为 "叶子节点存数据，非叶子节点存索引；叶子节点有序且相连"，具体细节如下：

分层设计 ：分为根节点、非叶子节点（中间层）、叶子节点。层级通常为 2-4 层（即使是千万级数据，B+ 树也能通过 3-4 次磁盘 IO 定位到数据，远优于全表扫描）。
- 非叶子节点：仅存储"索引键 + 子节点指针"，不存实际数据，目的是减少单次 IO 读取的数据量（磁盘按 "页" 读取，非叶子节点可容纳更多索引键，降低树的高度）。
- 叶子节点：存储"索引键 + 实际数据地址"（MyISAM）或"索引键 + 完整行数据"（InnoDB 主键索引），且所有叶子节点通过双向链表相连。
平衡特性：插入/删除数据时，自动调整树的结构，保证根节点到任意叶子节点的路径长度一致。
有序性 ：所有索引键在叶子节点按顺序排列，天然支持"排序"和"范围查询"（如 BETWEEN、>, < 等条件）。

虽然两者都用 B+ 树，但因存储引擎的 "数据存储方式" 不同，索引结构存在关键区别，核心是 "聚簇索引" vs "非聚簇索引"：

示例：查询 WHERE id=10（id 为主键）

注意：InnoDB 的 "回表" 问题 ------ 普通索引查询时，若需获取非索引列数据，需先查普通索引得到主键，再查主键索引获取完整数据（2 次索引查找）。可通过 "联合索引" 包含所需列（即 "覆盖索引" ）避免回表 。【InnoDB的回表问题可以通过覆盖索引解决】

哈希索引基于 "哈希表" 实现，核心是通过 "索引键的哈希值" 快速定位数据，仅 InnoDB 支持自适应哈希索引（非手动创建）。

结构特点：

存储"哈希值 + 行数据地址"：对索引键计算哈希值（如 hash(id)=0x123），哈希值映射到哈希表的桶，桶中存储行地址。
查找效率极高:理想情况下，1 次哈希计算即可定位数据（O (1) 时间复杂度），远快于 B+ 树的 O (log n)。
局限性明显（决定了其适用场景窄）：
- 不支持范围查询：哈希值是无序的（如 id=10 的哈希值可能大于 id=20），无法处理 BETWEEN、ORDER BY 等条件。
- 不支持前缀匹配：哈希值依赖完整索引键（如 name='张三' 的哈希值与 name='张' 无关），无法用于 LIKE '张%' 这类前缀查询。
- 哈希冲突：不同索引键可能计算出相同哈希值，需通过链表处理，冲突过多会导致效率下降。

适用场景：

仅适合 "等值查询 " 场景（如 WHERE id=10），且由 InnoDB 自动判断是否创建（当某列等值查询频率极高时，InnoDB 会在内存中构建自适应哈希索引，无需手动干预）。不建议手动依赖哈希索引。

R 树是专为 "空间数据" 设计的索引结构，用于存储和查询地理信息（如经纬度、区域范围），MySQL 中仅 MyISAM 支持，InnoDB 需通过 "空间索引" 间接实现类似功能。

结构特点：

适用场景：

全文索引用于 "文本内容的关键词搜索"（如文章内容、商品描述的关键词匹配），底层基于 "倒排索引"（Inverted Index）实现，MyISAM 和 InnoDB（5.6+）均支持。

结构特点：

倒排索引核心：将文本拆分为 "词项"（如 "MySQL 索引" 拆分为 "MySQL""索引"），存储 "词项 + 包含该词项的行 ID 列表"（如 "MySQL" 对应行 ID 1、3、5）。
支持关键词查询：如 MATCH(content) AGAINST('MySQL 索引')，可快速找到包含指定词项的行，且支持 "布尔模式"（如 +MySQL -索引，必须包含 MySQL 且不包含索引）。

适用场景 ：

替代低效的 LIKE '%关键词%'（全表扫描），用于大文本的关键词搜索（如博客系统、文档检索）。注意：仅支持 CHAR、VARCHAR、TEXT 类型列，且中文需通过插件（如 ngram）支持分词。

优先用 B+ 树索引：MySQL 中 99% 的场景依赖 B+ 树，无论是主键、普通索引还是联合索引，均基于 B+ 树设计，需重点理解其 "聚簇 / 非聚簇" 差异及 "回表 / 覆盖索引" 优化。
避免滥用特殊索引 ：哈希索引由 InnoDB 自适应管理，无需手动创建；R 树和全文索引仅在特定场景（空间数据、文本搜索）有用，否则会增加维护成本。
3.索引结构与性能强相关：设计索引时，需根据查询条件（如 "等值" 还是 "范围"）选择合适结构，例如：