MySQL常见的索引模型

索引是为了提高数据的查询效率，像书的目录一样

索引的常见模型

哈希表、有序数组、搜索树

• 哈希表
  哈希表是一种以键-值（key-value）存储数据的结构，只要输入待查找的值即 key，就可以找到对应的值即value
  哈希的思路，用一个哈希函数把key换算成一个确定的位置，把value放在数组的这个位置上。但是，多个key经过哈希函数的换算，会出现同一个值的情况，对于这种就拉出来一个链表

  假设，现在维护着一个身份证信息和姓名的表，需要根据身份证号查找对应的名字，这时对应的哈希索引的示意图如下：
  
  User2和User4根据身份证号算出来的值都是N。查ID_card_n2对应名字的步骤：首先，将ID_card_n2通过哈希函数算出N，按顺序遍历找到User2
  图中四个ID_card_n的值并不是递增的，这样的好处是增加新的User时速度回很快，只需要往后追加。
  缺点是哈希索引做区间查询的速度是很慢的，要全表扫描。
  个人理解：ID_card_n上建了索引，相当于key；User是对应的value；存储的时候key的值不是有序排列，所以查找某一区间范围内的ID，就要全表扫描

  哈希表这种结构适用于只有等值查询的场景

• 有序数组
  上述例子使用有序数组来实现的话，这个数组就是按照身份证号递增的顺序保存的。如果要查找ID_card_2对应的名字，用二分法就可以快速得到，时间复杂度O(log(N))

  但是，更新数据就很麻烦，往中间插入一个记录就必须挪动后面所有的记录，成本太高
  

  有序数组只适用于静态存储引擎（存入的数据不会再修改）

• 搜索树
  
  为了维持O(log(N)) 的查询复杂度，需要保持这棵树是平衡二叉树，更新的时间复杂度也是O(log(N)) 。二叉树是搜索效率最高的，但实际上大多数的数据库存储并不使用二叉树，因为索引不止存在内存中，还要写到磁盘上。
  每个树节点只存储了一个数据，一次磁盘IO只能取出来一个节点上的数据加载到内存里；如果一次查询涉及到多个节点，就会很耗费时间。设计数据库索引需要考虑尽可能减少磁盘IO次数。

InnoDB的索引模型

InnoDB使用了B+树索引模型，所以数据都是存储在B+树中的。磁盘IO有个特点，从磁盘读取1B数据和1KB数据所消耗的时间是基本一样的，我们可以在一个树节点上尽可能多的存储数据，一次磁盘IO就多加载点数据到内存，这就是B+树。
每一个索引在InnoDB里面对应一棵B+树。

每个节点上有多个索引字段的值。根据叶子节点的内容，索引类型分为主键索引和非主键索引。
主键索引的叶子节点存的是整行数据
非主键索引的叶子节点的内容是主键的值

主键索引和普通索引查询区别

select * from T where ID=500; // 即主键查询方式，只需要搜索ID这棵B+树
select * from T where k=5; 
// 普通索引查询方式，需要先搜索k索引树，得到ID=500，再到ID索引树搜索一次
// 上述称为回表

非主键索引的查询需要多扫描一棵索引树，因此应尽量使用主键查询

索引维护

B+树中索引是有序的
如果要插入数据的数据页已经满了，根据B+树算法，需要申请一个新的数据页，挪动部分数据过去。这个过程称为页分裂。这种情况下性能会受影响。

主键长度越小，普通索引的叶子节点就越小，普通索引占用的空间就越小

哪些场景要用自增主键，哪些场景用业务字段作为主键?

• 选用自增主键
  – 性能方面
  表中如果使用自增主键，插入新纪录的时候可以不指定ID的值，系统会获取当前ID最大值+1作为下一条记录的ID值
  每次插入一条新纪录都是追加操作，不涉及到挪动其他记录，也不会触发叶子节点的分裂
  业务字段做主键，不容易保证有序插入，写数据成本太高
  – 存储空间
  由于每个非主键索引的叶子节点都是主键的值，如果有多个二级索引的话，占用的空间会比较大
  主键长度越小，普通索引的叶子节点就越小，普通索引占用的空间就越小

  所以，从性能和存储空间考量，自增主键是更合理的选择。

• 选用业务字段做主键索引（满足以下2个条件）

  1. 只有一个索引（由于没有其他索引、不用考虑叶子节点大小问题）
  2. 该索引必须是唯一索引（因为主键索引是唯一索引）

Note：索引树中存放索引字段的所有值，并且是有序的（递增）

学习《MySQL实战45讲》