B-Tree Hash b+Tree三种索引特点对比

B-Tree（平衡多路查找树）--I/O操作，提高查询效率
[key,data]-----key 键值   data  数据   不同数据，key值不同
特性：
	1，	每个节点最多有m个孩子；
	2，除了根节点和叶子结点外，其他每个节点至少有Ceil（m/2）个孩子；
	3，若根节点不是叶子结点，则至少有两个孩子；
	4，所有叶子结点都在同一层，且不包含其他关键信息；
	5，每个非终端节点包含n个关键字信息（P0,P1,P2...Pn,K1,..Kn）；
	6,关键字的个数n满足：ceil(m/2) - 1 <= n <= m-1；
	7,ki(i = 1,...n) 为关键字，且关键字升序排序；
	8，Pi(i = 1,..n)指向子树根节点的指针，
	P（i-1）指向的子树的所有节点关键字均K(i-1);
	9,B-Tree 中的每个节点根据实际情况可以包含大量的关键字信息和分;
	10,每一个页的存储空间是有限的，如果data数据较大时将会导致每个节点（即一个页）能存储的key的数量很小，存储的数据量很大时同样会导致B-Tree的深度较大，增大查询时的磁盘I/O次数，进而影响查询效率;
	11,B-tree对索引是顺序组织存储的，所很适合进行查找范围数据;
	12,not in 和 <> 操作无法使用该索引;

ex

B+Tree--InnoDB存储引擎
B+Tree 是在B-Tree基础上的一种优化，使其更适合外存储索引结构
-------所有数据记录节点都是按照键值大小顺序存放在同一层的叶子节点上，而非叶子节点上只存储key值信息，这样可以大大加大每个节点存储的key值数量，降低B+Tree的高度.
B+Tree相对于B-Tree有几点不同：
1. 非叶子节点只存储键值信息。
2. 所有叶子节点之间都有一个链指针。
3. 数据记录都存放在叶子节点中。

ex2

HASH索引
HASH的特点
	1,Hash索引基于Hash表实现，只有查询条件精确匹配Hash索引中的所有列才会用到hash索引;
	只能用到等值查询，不能范围和模糊查询.
	2,存储引擎会为Hash索引中的每一列都计算hash码，Hash索引中存储的即hash码，所以每次读取都会进行两次查询;
	　使用哈市索引两次查找，第一次找到相应的行，第二次读取数据，但是被频繁访问到的行一般会缓存在内存中，这点对数据库性能的影响不大。
	3,Hash索引无法用于排序
	hash索引存储的是hash码而不是键值，所以无法用于外排序.
	4,Hash不适用于区分度小的列上，如性别字段;
	当出现hash冲突的时候，存储引擎必须遍历整个链表中的所有行指针，逐行比较，直到找到所有的符合条件的行，若hash冲突很多的话，一些索引的维护代价机会很高，所以说hash索引不适用于选择性很差的列上（重复值很多）。姓名、性别、身份证（合适） 
	*InnoDB的“自适应hash索引”。就是当InnoDB注意到某些索引值被使用的非常频繁时，它会在内存中基于B-Tree索引上在创建一个hash索引，这样就让B-tree索引也具有hash索引的一些优点。这是一个完全自动的内部的行为，用户无法控制或配置，不过，如果有需要，完全可以关闭该功能.
	5,Hash 索引仅仅能满足"=","IN"和"<=>"查询，不能使用范围查询。
	由于 Hash 索引比较的是进行 Hash 运算之后的 Hash 值，所以它只能用于等值的过滤，不能用于基于范围的过滤，因为经过相应的 Hash 算法处理之后的 Hash 值的大小关系，并不能保证和Hash运算前完全一样。
	6,Hash 索引在任何时候都不能避免表扫描;
	由于不同索引键存在相同 Hash 值，所以即使取满足某个 Hash 键值的数据的记录条数，也无法从 Hash 索引中直接完成查询，还是要通过访问表中的实际数据进行相应的比较，并得到相应的结果。
	7,Hash 索引无法被用来避免数据的排序操作;
	由于 Hash 索引中存放的是经过 Hash 计算之后的 Hash 值，而且Hash值的大小关系并不一定和 Hash 运算前的键值完全一样.
	8,Hash 索引不能利用部分索引键查询;
	通过组合索引的前面一个或几个索引键进行查询的时候，Hash 索引也无法被利用。
	9,Hash 索引遇到大量Hash值相等的情况后性能并不一定就会比B-Tree索引高;
	对于选择性比较低的索引键，如果创建 Hash 索引，那么将会存在大量记录指针信息存于同一个 Hash 值相关联。这样要定位某一条记录时就会非常麻烦，会浪费多次表数据的访问，而造成整体性能低下