MySQL是如何利用索引的？

什么是索引？

索引是数据库快速找到记录行的一种数据结构，类似我们看书时的目录，它是良好性能的关键因素。尤其是表中的数据量越来越大时，如果索引使用不当，会严重影响性能。索引也是最常见的数据库优化手段，它能轻易的将查询性能提高好几个量级。

MySQL索引类型？

mysql索引数据是存储在存储引擎中的，所以不同存储引擎中索引的工作方式并不一样。

B-Tree索引：基于B+树（一种多叉搜索数树）来实现的索引类型，一般也是使用的最多的索引类型，之所以选择B+树而不是其他数据结构，是因为B+树在查询时间复杂度可以维持在O(logn)的级别上，由于B+的矮胖（从根节点到叶子节点的距离可以维持在较小范围）特性减少磁盘IO次数、数据只存在叶子节点中并且按顺序存储也可以支持快速的范围查询，这是其他结构无法满足的！

B+索引中值是按顺序存储的，叶子节点到根节点的距离都相同，从B+树的根节点开始往下查找，节点存储了指向叶子节点的指针，通过将要查找的值和每个节点值比较后，一层层定位到最终的叶子结点上，叶子节点存储的就是行数据、指针或主键。

假如我们索引列是：

key（lastname（姓）,firstname（名）,born），可以使用B+树索引的查询类型包括：全键值、键值范围、键前缀查找，其中键前缀只适用于最左前缀查找：

• 全值匹配：指的是和索引中所有的列进行匹配，如可以找到姓名为：Cuba（名） Allen(姓) 、生于1988-10-04的人，如where lastname=‘Allen’ and firstname=‘Cuba’ and born='1988-10-04'
• 匹配最左前缀：可以查找姓为Allen的人，如where lastname=‘Allen’
• 匹配列前缀：也可以匹配某一列的值的开头部分，如where lastname like ‘A%’ 或者where firstname like ‘M%’
• 匹配范围：可以匹配姓在Allen和Bill之间的人
• 精确匹配某一列并匹配另外一列：查找所有姓为Allen、并且名字是以M开头的人，如where lastname=‘Allen’ and firstname like ‘M%’
• 访问索引数据：这种查询只需要访问索引本身就行了，不需要访问数据行，也就是常说的索引覆盖，举个例子：如果只需要找到姓为Allen的人的名称， 而不需要这个人其他的信息，名称就存在与索引中，不需要再去数据行中查找数据了。

这里需要注意的是叶子节点存什么类型数据不同的存储引擎还不一样，在MyISAM中叶子节点存储的是数据物理位置（指针），而InnoDB使用B+结构存储的是原始数据或主键，也就是我们常说的聚簇索引，它存储的是原始全量数据、键值，聚簇索引指的是一种数据索引组织形式，它将数据和索引聚集在一起所以叫聚簇，它本身并不是一种索引类型。

一般InnoDB查找过程为从辅助索引上开始查找到数据主键，然后在主键索引中用主键再次查找，最后再找到数据，虽然多了一次查找过程，但更新数据不会导致聚簇索引频繁变化。而在MyISAM中不需要2次索引查找，因为叶子节点存储的是数据的物理地址可以直接定位，虽然查询看似简单了，但是物理地址会因为数据频繁变更而发生变化。

假设有以下数据：

InnoDB（聚簇索引）数据查找过程：

MyISAM（非聚簇索引结构）数据查找过程：

哈希索引：基于哈希表来实现的索引类型，如果存在哈希冲突，索引会使用链表来存放多个记录到一个哈希桶中。举个例子：如果存在以下索引 key USING HASH（firstname），哈希索引会使用哈希函数计算出firstname列的哈希值作为key，并将行指针作为value存储，当使用 =、IN（）、<=>操作时，先计算出sql语句操作查找值的哈希值，并使用其来查找哈希表对应的行指针，从而返回数据。

这里需要注意是：

• 哈希索引只存储哈希值和行指针，索引索引本身没有行数据，也就没有所谓的索引覆盖。
• 哈希索引没有按哈希值的顺序排列，所有不支持排序操作。
• 不支持部分索引列的匹配，哈希索引使用你指定的全部列来计算哈希值，列入（A，B）如果查询只有列A，则索引无发匹配。
• 哈希索引只支持等值比较（=、in(),<=>）。
• 哈希冲突较高时，查找效率就变成了链表，复杂度从O（1）变为O（n）。

空间数据索引：MyISAM支持空间索引可以用来存储地理数据。必须使用GIS相关函数如MBRCONUNTAINS（）来维护数据，因为本身mysql对GIS的支持下不完善，这中特性使用很少。

全文索引：这是一种特殊类型的索引，他查找的是索引列中文本的关键词，而不是比较索引值，全文索引的使用要注意列的文本大小和数据量，它的匹配方式类似于搜索引擎。

索引的优缺点？

• 大大减少了服务器扫描表的数据量。
• 避免不必要的排序和临时表。
• 将随机IO变为顺序IO。
• 对于非常小的表，全表扫描可能比索引更快，对于中型数据量表，索引将会非常有效，对于TB级别的表来说，索引的维护和效果可能没有我们想象的那样好，这是可以使用表分区、业务拆分表和分库等技术。

常见的索引优化方式及注意事项？

• 不要把索引的列纳入表达式，也不能是函数参数，如where aid+1=5、where to_days（col）<=10.
• 选择重复性较低的列建索引，重复性较高会导致索引失效，全表扫描。
• 多列索引中很多常见的错误是，喜欢为每个列创建独立索引，实际上这是错误的！要选择合适的顺序和列来合并索引，来看个简单例子：

表数据为：

分别建2个独立索引：inx_name, inx_company ：

现在执行以下语句：

SELECT * from tuser where `name`='22' or company='bb'

结果显示并没有使用索引来查询数据：

现在加一个多列索引：inx_name_company

执行同样的sql显示使用了多列索引：

• 不要在大文本字段建全量索引，这会然导致索引数据较大，查询较慢，可以建一个前缀索引，例如

//在city列上取前7个字符作为索引 mysql > alter table demo add key(city(7))

这是一种使索引更小，更快的方法，但缺点是无法使用缀索引order by或group by