MySQL实战45讲（From 极客时间）学习笔记（4）

04 | 深入浅出索引（上）

　　说实话，从前学数据库的时候，对索引这一块就是一带而过。在上课时也只是了解了其基本概念，有什么作用以及使用的语句，但并不理解索引在实际应用中发挥的作用，以及索引在底层的实现与执行原理（主要还是因为本科期间做的所谓项目，根本不需要使用索引。基本的增删改查语句已经几乎满足了那些应用需求）。而本节，将更深刻地学习这一概念。（虽然学完还是不能完全理解在应用中作用，希望日后能有机会接触到真正足够规模的开发工作）

　　一句话简单来说，索引的出现其实就是为了提高数据查询的效率，就像书的目录一样。这句话倒是跟书本上的相差无几。我自己从SQL的语句上理解，大概就是在查询该表时，通过以某种或某些属性值建立一个目录，并以此加快查询速度。

 

索引的常见模型

　　本节首先介绍了三个比较简单的实现索引的数据结构：哈希表、有序数组、搜索树。这些大概只要上过数据结构与算法课都应该了解是什么东西，因此也就不再赘述。

　　哈希表优缺点。在设计哈希表时，通常防冲突的做法是通过将同一哈希值的节点置于同一链表。因此，在此处的哈希表也可认为是链表数组。这样的好处是，当有新数据加入时，可以直接尾插法进行添加。但缺点在于，这些链表并非有序。所以，哈希表只适用于等值查询，而非区间查询。

　　有序数组优缺点。有序数组在等值查询和区间查询上的表现非常可观。同样地，上过数据结构课的同学们都记得会有查找那一章。那一章里介绍了如二分查找、斐波那契查找等查找算法就是基于有序数组的查找算法。通过使用这些算法进行等值查询和区间查询能够提升其查询效率。但有序数组只能适用于静态存储引擎，因为当添加新数据时，维护有序数组的成本较高。

　　二叉搜索树。同样也是常见的数据结构。二叉搜索树理论上的搜索效率应该是三者之中最高的，但为了维护其搜索效率，这里的二叉搜索树应是AVL树。但其维护成本，同时存储成本，包括写磁盘等操作的成本，使得这一数据结构基本不会被用于实现索引。

　　因此，又一熟悉的数据结构便得到了发挥，那就是B+树。

 

InnoDB的索引模型

　　关于 InnoDB 的表结构： 1.在 InnoDB 中，每一张表其实就是多个 B+ 树，即一个主键索引树和多个非主键索引树。 2.执行查询的效率，使用主键索引 > 使用非主键索引 > 不使用索引，注：非主键索引效率低于主键索引是因为非主键索引查询到的是该字段对应主键，还需要对主键索引回表，才能查询到需要的数据。 3.如果不使用索引进行查询，则从主索引 B+ 树的叶子节点进行遍历。

　　因此，我们在应用中应该尽量使用主键查询。

 

索引维护

　　学习过B+树的应该还记得维护B+树麻烦的点在于，除了需要保证其有序性，还需要保证它的阶数。因此，在插入节点与删除节点时，经常会使用到节点分裂或合并的操作。但如果使用自增主键的插入数据模式，每次插入一条新记录，都是追加操作，都不涉及到挪动其他记录，也不会触发叶子节点的分裂，从而降低了维护成本。

　　同时，主键长度越小，普通索引的叶子节点就越小，普通索引占用的空间也就越小。因此，从存储成本和维护成本来看，一般自增主键的方式都是较为合理的选择。