第四讲 深入浅出索引（上）总结

第四讲 深入浅出索引（上）总结

一、索引概述

目的与概念

• **索引的出现是为了提高数据查询效率，如同书的目录。**对于数据库表而言，它是重要概念，在数据库系统中扮演关键角色。在 MySQL 中，索引在存储引擎层实现，不同存储引擎工作方式不同，InnoDB 使用最为广泛。

索引模型

• 哈希表：以键 - 值存储数据，通过哈希函数确定值在数组中的位置，可能出现多个键值映射到同一位置，通过链表解决冲突。适用于只有等值查询的场景，如 Memcached 及其他一些 NoSQL 引擎。但由于数据无序，区间查询速度慢。例如下图，根据身份证号查找名字，若用哈希索引，查找特定身份证号对应的名字时，先通过哈希函数计算位置，再遍历链表。若要查找身份证号在某区间的用户，需全部扫描。

  • 适用场景：哈希表这种结构适用于只有等值查询的场景，比如Memcached及其他一些NoSQL引 擎。

  

• 有序数组：**在等值查询和范围查询场景性能优秀。**例如用有序数组实现身份证号查名字，数组按身份证号递增顺序保存，查找特定身份证号对应的名字可用二分法，时间复杂度为 O (log (N))，也支持范围查询。但更新数据时成本高，往中间插入记录需挪动后面所有记录，只适用于静态存储引擎，如保存特定年份城市人口信息等不会再修改的数据。
  

• 二叉搜索树：每个节点左儿子小于父节点，父节点小于右儿子，查询时间复杂度为 O (log (N))。为维持查询复杂度，更新时间复杂度也为 O (log (N))。二叉树查询效率高，但数据库存储多不使用二叉树，因为索引要写到磁盘上，二叉树树高可能较大，查询时访问磁盘次数多，速度慢。为减少读磁盘次数，使用 “N 叉” 树，N 取决于数据块大小，如 InnoDB 整数字段索引 N 约为 1200，“N 叉” 树已广泛应用于数据库引擎中。

  

二、InnoDB 索引模型

1. 存储方式

   • InnoDB 中表根据主键顺序以索引形式存放，是索引组织表，使用 B + 树索引模型，数据存储在 B + 树中。每个索引对应一棵 B + 树。主键索引叶子节点存整行数据，也称聚簇索引；非主键索引叶子节点内容是主键的值，也称二级索引。

     

2. 查询区别

   • 基于主键索引查询（如 select * from T where ID = 500）只需搜索 ID 这棵 B + 树；
   • 基于普通索引查询（如 select * from T where k = 5）需先搜索 k 索引树得到 ID 值，再到 ID 索引树搜索一次，此过程称为回表，基于非主键索引的查询需多扫描一棵索引树，所以应用中应尽量使用主键查询。

三、索引维护

1. B + 树维护操作
   • B + 树为维护索引有序性，插入新值时有不同情况。如插入新行 ID 值大于当前最大值，直接在叶子节点末尾插入；若插入值在中间，可能需逻辑挪动后面数据空出位置；若插入数据页已满，会发生页分裂，申请新数据页并挪动部分数据过去，这会影响性能和数据页利用率，相邻页利用率低时会合并，可视为分裂逆过程。
2. 自增主键与业务字段做主键分析
   • 自增主键插入数据模式符合递增插入场景，每次追加操作，不涉及挪动其他记录和叶子节点分裂，性能较好。从存储空间看，主键长度越小，普通索引叶子节点越小，占用空间越小，所以自增主键在性能和存储空间方面往往更合理。但有业务场景适合用业务字段直接做主键，如只有一个索引且必须是唯一索引的 KV 场景，此时优先考虑 “尽量使用主键查询” 原则，可避免每次查询搜索两棵树。

四、总结

• 介绍了哈希、有序数组和二叉搜索树的索引模型，并介绍了他们的优缺点和适用场景。
• 分析了数据库引擎可用的数据结构，介绍了InnoDB采用的B+树结构，以及为什么 InnoDB要这么选择。
• B+树能够很好地配合磁盘的读写特性，减少单次查询的磁盘访问次数。 由于InnoDB是索引组织表，一般情况下创建一个自增主键，这样非主键索引占用的 空间最小。但事无绝对，我也跟你讨论了使用业务逻辑字段做主键的应用场景。