对于数据库的索引，相信各位看官不会陌生。在如今面试过程中，数据库方面的一个重要发难环节，即是数据库索引及优化，甚至还有一些吊书袋的人会专门针对数据库的索引规则，提出一些奇葩且无聊的问题。相比之下，了解了索引的妙用在实际中加以巧用，应该更能令人开心。不论如何，雷记希望和大家分享一些关于索引的东西:）
关于索引
索引在数据库中以指定的数据结构存储，在存储引擎查找时可以起到提速的检索功能。索引对于项目的性能影响，在数据量越来越大时越明显，很不凑巧的是索引在我们日常处理项目中，会被忽略掉、被误解，还有一系列糟糕的索引创建，所以在项目的性能压迫我们的神经线时，我们会下意识地考虑从索引优化下手，甚至可以达到提高几个数量级性能的结果，毕竟在项目开发中对于sql的使用可以糟糕到什么程度是无法感知的。
mysql处理查询时，先按值在索引上进行查找，然后返回所有包含这个值的数据行，索引可以包含多个列的值，mysql只能高效地使用索引的最左前缀列，所以多个列的顺序很重要。
这里有一个较为有趣的问题，即如果我们使用orm工具，是不是仍要关注索引的问题？答案是需要的，orm的智能程度和使用方法，会导致查询类的语句无法适合索引的生效规则，不论orm工具多么地复杂高深，在设计精妙和复杂巧妙地索引设计对比之下，都是不堪一击的。
索引的类型
索引的类型因使用场景不同而不同，mysql中索引是在存储引擎层实现的，不同存储引擎的索引工作方式不同，而且各种各样的存储引擎也不是支持所有类型的索引，对于索引实际是没有统一的规则或者标准。
B-Tree
因为语言的歧义性和习俗约定的原因，我们日常说的索引，没有指明类型时，一般是b-tree索引，大多数的mysql存储引擎都支持它，当然其中不包括archive引擎，它在5.1之后的版本才只能支持auto_increment单个自增列索引。
b-tree索引使用b-tree数据结构来存储数据，底层的存储引擎可能使用不同的存储结构，ndb集群存储引擎内部实际使用t-tree，innodb使用b+tree，关于各类的数据结构和算法的变种，雷记后续会整理一些帖子或者在个人博客里详细分解一番，在这里先不做赘述。由于存储引擎们以不同的方式存储b-tree，导致性能也是各有不同，如innodb（按原数据格式存储）根据主键引用被索引的行，myisam（使用前缀压缩技术使索引尽可能地小）通过数据的物理位置引用被索引的行。
b-tree索引能够加快访问数据的速度，是由于存储引擎不必在对全表进行扫描，而是从索引的根节点进行搜索，然后根据子节点的指针进行下层查找，通过比较节点页的值和要查找的值，确定进入下层的节点，最终引擎要么找到对应的值要么得到一个要查找的记录不存在的结果，另外由于b-tree对索引是顺序组织存储，所以很适合查找范围数据的场景。
b-tree索引适用地查询类型
·全值匹配：
和索引中的所有列进行匹配；
·匹配最左前缀：
只使用索引的第一列；
·匹配列前缀：
只匹配某一列的值的开头，也是只使用索引第一列；
·匹配范围值：
只用索引的第一列，查询值位于查询范围的记录；
·精确匹配某一列并范围匹配另外一列：
类似使用两列，第一列精确匹配，第二列模糊匹配；
·只访问索引的查询：
b-tree支持只访问索引，不访问数据行。
b-tree适用于全键值、键值、键前缀查找（只适用于最左前缀查找），因为索引树中节点都是有序，所以除了按值查找，索引也可以用于查询中order by按顺序查找，也就是说，如果b-tree可以按照某种方式查到值，那么也可以按这个方式用于排序结果。
b-tree索引的使用限制
·不是按索引的最左列开始查找，无法使用索引；
·索引中的列无法跳过；
·如果是查询某个列的范围，那么该列右侧所有列无法使用索引优化查询；
今天的关于b-tree索引的分享大致就是这样，可以看到索引列的顺序是十分的重要，查询的效用也是和索引列的顺序有关。在日常开发中有很多的场景使用b-tree索引可以带来很好的优化效果，但是诸多的限制也让我们颇为不爽，下一篇帖子中让我们继续来聊一下哈希索引。
