数据库索引

     数据库的索引，使用比较多了，但是对于原理一直懵懂，今天来彻底整理一下。

索引的2种数据结构：

  1.平衡树（非二叉；主流的关系型数据库一般都默认用它，MySQL里常用的索引数据结构有B+树索引和哈希索引两种）

  2.哈希桶

备注：先说下，在MySQL文档里，实际上是把B+树索引写成了BTREE。

一.平衡树

     首先这里只b+tree，关于B树概念，可自行百度。通过学习发现它是平衡多叉树，可以减少访问磁盘的次数，更为形象的说法就是降低树的高度，减少磁盘的I/O次数，优化磁盘访问的速度。而索引的结构组织就是要尽量减少查找过程中磁盘I/O的存取次数。 

B+树

   B+树可以看作是B树的一种变形，在实现文件索引结构方面比B树使用得更普遍。

   一个m阶的B+树具有如下几个特征：

• 树中每个非叶结点最多有 m 棵子树；
• 根结点 (非叶结点) 至少有 2 棵子树。除根结点外, 其它的非叶结点至少有 m/2 棵子树；有 n 棵子树的非叶结点有 n-1 个关键码。
• 所有叶结点都处于同一层次上，包含了全部关键码及指向相应数据对象存放地址的指针，且叶结点本身按关键码从小到大顺序链接；
• 每个叶结点中的子树棵数 n 可以多于 m，可以少于 m，视关键码字节数及对象地址指针字节数而定。
• 若设结点可容纳最大关键码数为 m1，则指向对象的地址指针也有 m1 个。
• 结点中的子树棵数 n 应满足 n 属于[m1/2, m1]
• 若根结点同时又是叶结点，则结点格式同叶结点。
• 所有的非叶结点可以看成是索引部分，结点中关键码 Ki 与指向子树的指针 Pi 构成对子树 (即下一层索引块) 的索引项 ( Ki, Pi )，Ki 是子树中最小的关键码。
• 特别地，子树指针 P0 所指子树上所有关键码均小于 K1。结点格式同B树。
• 叶结点中存放的是对实际数据对象的索引。
• 在B+树中有两个头指针：一个指向B+树的根结点，一个指向关键码最小的叶结点。

B+树结构图：

如上图，是一颗b+树，关于b+树的定义可以参见B+树，浅蓝色的块我们称之为一个磁盘块，可以看到每个磁盘块包含几个数据项（深蓝色所示）和指针（黄色所示），如磁盘块1包含数据项17和35，包含指针P1、P2、P3，P1表示小于17的磁盘块，P2表示在17和35之间的磁盘块，P3表示大于35的磁盘块。真实的数据存在于叶子节点即3、5、9、10、13、15、28、29、36、60、75、79、90、99。非叶子节点只不存储真实的数据，只存储指引搜索方向的数据项，如17、35并不真实存在于数据表中。

b+树的查找过程

         如图所示，如果要查找数据项29，那么首先会把磁盘块1由磁盘加载到内存，此时发生一次IO，在内存中用二分查找确定29在17和35之间，锁定磁盘块1的P2指针，内存时间因为非常短（相比磁盘的IO）可以忽略不计，通过磁盘块1的P2指针的磁盘地址把磁盘块3由磁盘加载到内存，发生第二次IO，29在26和30之间，锁定磁盘块3的P2指针，通过指针加载磁盘块8到内存，发生第三次IO，同时内存中做二分查找找到29，结束查询，总计三次IO。真实的情况是，3层的b+树可以表示上百万的数据，如果上百万的数据查找只需要三次IO，性能提高将是巨大的，如果没有索引，每个数据项都要发生一次IO，那么总共需要百万次的IO，显然成本非常非常高。

哈希桶

      为了解决线性探测实现哈希表时出现哈希冲突后导致数据堆聚的现象，我们采取了另一种结构来处理哈希冲突，哈希桶（拉链法），拉链法解决哈希冲突的做法是将所有通过哈希函数计算出来的哈希地址相同的结点存放在一个单链表之中。 
实现原理就是将哈希表定义为一个由N个头指针组成的指针数组，经过哈希函数计算得到的哈希地址相同的数据全部连在对于的头指针下面。它继承了数组的易于查找和链表便于删除插入的特点。

        哈希索引是基于哈希表实现的。只有精确匹配索引所有列的的查询才有效。他的实现是存储殷勤会对每一行数据的索引列计算哈希码，并将哈希码和指向该记录的指针维护起来，对于hash相同的，采用链表的方式解决冲突。hashmap的数据结构。因为索引的结构是十分紧凑的，所以hash索引的查询很快。
但是hash索引也有他的限制：
1，hash索引只包含了哈希值和行指针，索引不能避免读取行，不能使用覆盖索引。
2，hash索引并不是按照索引顺序存储的，无法用于排序。
3，hash索引不支持部分或者区域查找，部分列的hash结果是不同的。
在Mysql中InnoDB引擎有一个特殊的功能叫做自适应哈希索引，他会在内存中基于B-Tree索引的基础上面创建一个哈希索引，这让B-Tree索引页具备了一些哈希索引的优点。

索引原理：
     一般来说，索引本身也很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储在磁盘上。这样的话，索引查找过程中就要产生磁盘I/O消耗，相对于内存存取，I/O存取的消耗要高几个数量级。 
所以评价一个数据结构作为索引的优劣最重要的指标就是在查找过程中磁盘I/O操作次数的渐进复杂度。 
换句话说，索引的结构组织要尽量减少查找过程中磁盘I/O的存取次数。 

索引优化

    1.  MySQL的优化主要分为结构优化（Scheme optimization）和查询优化（Query optimization）。

    2.优化策略

• 最左前缀匹配原则
• 主键外检一定要建索引
• 对 where,on,group by,order by 中出现的列使用索引
• 尽量选择区分度高的列作为索引,区分度的公式是count(distinct col)/count(*)，表示字段不重复的比例，比例越大我们扫描的记录数越少，唯一键的区分度是1，而一些状态、性别字段可能在大数据面前区分度就是0
• 对较小的数据列使用索引,这样会使索引文件更小,同时内存中也可以装载更多的索引键
• 索引列不能参与计算，保持列“干净”，比如from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，原因很简单，b+树中存的都是数据表中的字段值，但进行检索时，需要把所有元素都应用函数才能比较，显然成本太大。所以语句应该写成create_time = unix_timestamp(’2014-05-29’);
• 为较长的字符串使用前缀索引
• 尽量的扩展索引，不要新建索引。比如表中已经有a的索引，现在要加(a,b)的索引，那么只需要修改原来的索引即可
• 不要过多创建索引, 权衡索引个数与DML之间关系，DML也就是插入、删除数据操作。这里需要权衡一个问题，建立索引的目的是为了提高查询效率的，但建立的索引过多，会影响插入、删除数据的速度，因为我们修改的表数据，索引也需要进行调整重建
• 对于like查询，”%”不要放在前面。 
  SELECT * FROM houdunwang WHERE uname LIKE'后盾%' -- 走索引 
SELECT * FROM houdunwang WHERE uname LIKE "%后盾%" -- 不走索引
• 查询where条件数据类型不匹配也无法使用索引 
  字符串与数字比较不使用索引; 
  CREATE TABLEa(achar(10)); 
EXPLAIN SELECT * FROMaWHEREa="1" – 走索引 
  EXPLAIN SELECT * FROM a WHERE a=1 – 不走索引 
  正则表达式不使用索引,这应该很好理解,所以为什么在SQL中很难看到regexp关键字的原因。
• 更多可以参考MySQL索引优化规则

参考文献：https://blog.csdn.net/crystal6918/article/details/78073721

                   https://blog.csdn.net/MBuger/article/details/62418754

                   https://blog.csdn.net/wx145/article/details/82839419

                   https://blog.csdn.net/u011504963/article/details/79727849