[MySQL] MySQL索引原理及优化

一  索引的本质

　　MySQL官方对索引的定义为：索引（Index）是帮助MySQL高效获取数据的数据结构。提取句子主干，就可以得到索引的本质：索引是数据结构。

　　数据库查询是数据库的最主要功能之一。我们都希望查询数据的速度能尽可能的快，因此数据库系统的设计者会从查询算法的角度进行优化。

　　最基本的查询算法当然是顺序查找（linear search），这种复杂度为O(n)的算法在数据量很大时显然是糟糕的，好在计算机科学的发展提供了很多更优秀的查找算法，例如二分查找（binary search）、二叉树查找（binary tree search）等。如果稍微分析一下会发现，每种查找算法都只能应用于特定的数据结构之上，例如二分查找要求被检索数据有序，而二叉树查找只能应用于二叉查找树上，但是数据本身的组织结构不可能完全满足各种数据结构（例如，理论上不可能同时将两列都按顺序进行组织）。

　　所以，在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法。这种数据结构，就是索引。

　　

　　图片展示了一种可能的索引方式。左边是数据表，一共有两列七条记录，最左边的是数据记录的物理地址（注意逻辑上相邻的记录在磁盘上也并不是一定物理相邻的）。为了加快Col2的查找，可以维护一个右边所示的二叉查找树，每个节点分别包含索引键值和一个指向对应数据记录物理地址的指针，这样就可以运用二叉查找在O(log2n)的复杂度内获取到相应数据。

二  各种数据结构介绍

　　这一小节结合哈希表、完全平衡二叉树、B树以及B+树的优缺点来介绍为什么选择B+树。

　　假如有这么一张表(表名：sanguo)：

　　

（1）Hash索引

　　对name字段建立哈希索引：

　　

　　根据name字段值进行hash计算，定位到数组的下标，因为字段值所对应的数组下标是哈希算法随机算出来的，所以可能出现哈希冲突。其中每一个节点存储的是name字段值及对应的行数据地址，那么对于这样一个索引结构，现在来执行下面的sql语句： 　

　　select * from sanguo where name = '周瑜';

　　可以直接对‘周瑜’按哈希算法算出来一个数组下标，然后可以直接从数据中取出数据并拿到所对应那一行数据的地址，进而查询那一行数据。 那么如果现在执行下面的sql语句：

　　select * from sanguo where name > '周瑜'

　　则需要进行全表扫描，因为哈希表的特点就是可以快速的精确查询，但是不支持范围查询。

（2）完全平衡二叉树

　　针对上面的表数据用完全平衡二叉树表示如下图：

　　图中的每一个节点实际上应该有四部分：（1）左指针，指向左子树；（2）键值；（3）键值所对应的行数据的存储地址；（4）右指针，指向右子树

　　二叉树是有顺序的，即节点的左子树中的值要严格小于该节点的值，节点右子树中的值要严格大于该节点的值，如果查找‘周瑜’，需要找2次（第一次曹操，第二次周瑜），比哈希表要多一次。而且由于完全平衡二叉树是有序的，所以也是支持范围查找的。

（3）B-Tree

　　还是上面的表数据用B树表示如下图：

　　可以发现同样的元素，B树的表示要比完全平衡二叉树要“矮”，原因在于B树中的一个节点可以存储多个元素。同时，B树种每一个节点均存储了索引值及对应的行数据的指针。

（4）B+Tree

　　还是上面的表数据用B+树表示如下图（为了简单，数据对应的地址就不画在图中了。）：

　　我们可以发现同样的元素，B+树的表示要比B树要“胖”，原因在于B+树中的非叶子节点只存储索引键值而不存储行数据地址等相关数据，非叶子节点会冗余一份在叶子节点中，所有的行数据或者行数据地址只存储在叶子节点中，并且叶子节点之间用指针相连。在B+Tree的每个叶子节点增加一个指向相邻叶子节点的指针，就形成了带有顺序访问指针的B+Tree。做这个优化的目的是为了提高区间访问的性能，例如图4中如果要查询key为从18到49的所有数据记录，当找到18后，只需顺着节点和指针顺序遍历就可以一次性访问到所有数据节点，极大提到了区间查询效率。

二、为什么选择B+树？

　　索引也是很“大”的，因为索引也是存储元素的，我们的一个表的数据行数越多，那么对应的索引文件其实也是会很大的，实际上索引也是需要存储在磁盘中的，而不能全部都放在内存中，这样的话，索引查找过程中就要产生磁盘I/O消耗，相对于内存存取，I/O存取的消耗要高几个数量级。

　　所以我们在考虑选用哪种数据结构时，我们可以换一个角度思考，哪个数据结构更适合从磁盘中读取数据，或者哪个数据结构能够提高磁盘的IO效率。换句话说，索引的结构组织要尽量减少查找过程中磁盘I/O的存取次数。

　　假如用完全平衡二叉树作为索引的数据结构，当我们需要查询“张飞”时，需要以下步骤

1. 从磁盘中取出“曹操”到内存，CPU从内存取出数据进行比较，“张飞”<“曹操”，取左子树（产生了一次磁盘IO）

2. 从磁盘中取出“周瑜”到内存，CPU从内存取出数据进行比较，“张飞”>“周瑜”，取右子树（产生了一次磁盘IO）

3. 从磁盘中取出“孙权”到内存，CPU从内存取出数据进行比较，“张飞”>“孙权”，取右子树（产生了一次磁盘IO）

4. 从磁盘中取出“张飞”到内存，CPU从内存取出数据进行比较，“张飞”=“张飞”，找到结果（产生了一次磁盘IO）

　　假如使用B树，只发送三次磁盘IO就可以找到“张飞”了，这就是B树的优点：一个节点可以存储多个元素，相对于完全平衡二叉树所以整棵树的高度就降低了，磁盘IO效率提高了。

　　而B+树是B树的升级版，只是把非叶子节点冗余一下，这么做的好处是为了提高范围查找的效率。

到这里可以总结出来，Mysql选用B+树这种数据结构作为索引，可以提高查询索引时的磁盘IO效率，并且可以提高范围查询的效率，并且B+树里的元素也是有序的。

主存存取原理

　　目前计算机使用的主存基本都是随机读写存储器（RAM），现代RAM的结构和存取原理比较复杂，这里本文抛却具体差别，抽象出一个十分简单的存取模型来说明RAM的工作原理。

　　

　　从抽象角度看，主存是一系列的存储单元组成的矩阵，每个存储单元存储固定大小的数据。每个存储单元有唯一的地址，现代主存的编址规则比较复杂，这里将其简化成一个二维地址：通过一个行地址和一个列地址可以唯一定位到一个存储单元。图5展示了一个4 x 4的主存模型。

主存的存取过程如下：

　　当系统需要读取主存时，则将地址信号放到地址总线上传给主存，主存读到地址信号后，解析信号并定位到指定存储单元，然后将此存储单元数据放到数据总线上，供其它部件读取。

　　写主存的过程类似，系统将要写入单元地址和数据分别放在地址总线和数据总线上，主存读取两个总线的内容，做相应的写操作。

　　这里可以看出，主存存取的时间仅与存取次数呈线性关系，因为不存在机械操作，两次存取的数据的“距离”不会对时间有任何影响，例如，先取A0再取A1和先取A0再取D3的时间消耗是一样的。

磁盘存取原理

　　索引一般以文件形式存储在磁盘上，索引检索需要磁盘I/O操作。与主存不同，磁盘I/O存在机械运动耗费，因此磁盘I/O的时间消耗是巨大的。

　　盘片被划分成一系列同心环，圆心是盘片中心，每个同心环叫做一个磁道，所有半径相同的磁道组成一个柱面。磁道被沿半径线划分成一个个小的段，每个段叫做一个扇区，每个扇区是磁盘的最小存储单元。为了简单起见，我们下面假设磁盘只有一个盘片和一个磁头。

　　当需要从磁盘读取数据时，系统会将数据逻辑地址传给磁盘，磁盘的控制电路按照寻址逻辑将逻辑地址翻译成物理地址，即确定要读的数据在哪个磁道，哪个扇区。为了读取这个扇区的数据，需要将磁头放到这个扇区上方，为了实现这一点，磁头需要移动对准相应磁道，这个过程叫做寻道，所耗费时间叫做寻道时间，然后磁盘旋转将目标扇区旋转到磁头下，这个过程耗费的时间叫做旋转时间。

局部性原理与磁盘预读

　　由于存储介质的特性，磁盘本身存取就比主存慢很多，再加上机械运动耗费，磁盘的存取速度往往是主存的几百分之一，因此为了提高效率，要尽量减少磁盘I/O。为了达到这个目的，磁盘往往不是严格按需读取，而是每次都会预读，即使只需要一个字节，磁盘也会从这个位置开始，顺序向后读取一定长度的数据放入内存。这样做的理论依据是计算机科学中著名的局部性原理：

　　当一个数据被用到时，其附近的数据也通常会马上被使用。

　　程序运行期间所需要的数据通常比较集中。

　　由于磁盘顺序读取的效率很高（不需要寻道时间，只需很少的旋转时间），因此对于具有局部性的程序来说，预读可以提高I/O效率。

　　预读的长度一般为页（page）的整倍数。页是计算机管理存储器的逻辑块，硬件及操作系统往往将主存和磁盘存储区分割为连续的大小相等的块，每个存储块称为一页（在许多操作系统中，页得大小通常为4k），主存和磁盘以页为单位交换数据。当程序要读取的数据不在主存中时，会触发一个缺页异常，此时系统会向磁盘发出读盘信号，磁盘会找到数据的起始位置并向后连续读取一页或几页载入内存中，然后异常返回，程序继续运行。

三  一个B+树的节点中到底存多少个元素合适呢？

　　其实也可以换个角度来思考B+树中一个节点到底多大合适？

　　答案是：B+树中一个节点为一页或页的倍数最为合适。因为如果一个节点的大小小于1页，那么读取这个节点的时候其实也会读出1页，造成资源的浪费；如果一个节点的大小大于1页，比如1.2页，那么读取这个节点的时候会读出2页，也会造成资源的浪费；所以为了不造成浪费，所以最后把一个节点的大小控制在1页、2页、3页、4页等倍数页大小最为合适。

　　那么，Mysql中B+树的一个节点大小为多大呢？

　　这个问题的答案是“1页”，这里说的“页”是Mysql自定义的单位（其实和操作系统类似），Mysql的Innodb引擎中一页的默认大小是16k（如果操作系统中一页大小是4k，那么Mysql中1页=操作系统中4页），可以使用命令SHOW GLOBAL STATUS like 'Innodbpagesize'; 查看。

　　并且还可以告诉你的是，一个节点为1页就够了。

　　为什么一个节点为1页（16k）就够了？解决这个问题，我们先来看一下Mysql中利用B+树的具体实现。

四  Mysql中MyISAM和Innodb使用B+树

　　

　　通常我们认为B+树的非叶子节点不存储数据，只有叶子节点才存储数据；而B树的非叶子和叶子节点都会存储数据，会导致非叶子节点存储的索引值会更少，树的高度相对会比B+树高，平均的I/O效率会比较低，所以使用B+树作为索引的数据结构，再加上B+树的叶子节点之间会有指针相连，也方便进行范围查找。上图的data区域两个存储引擎会有不同。

1  MyISAM中的B+树

　　MYISAM中叶子节点的数据区域存储的是行数据记录的地址

　　MyISAM主键索引：

　　

　　MyISAM辅助索引：

　　

　　MyISAM存储引擎在使用索引查询数据时，会先根据索引查找到行数据地址，再根据地址查询到具体的数据。

　　MyISAM的索引文件仅仅保存数据记录的地址。在MyISAM中，主索引和辅助索引（Secondary key）在结构上没有任何区别，只是主索引要求key是唯一的，而辅助索引的key可以重复。

　　因此，MyISAM中索引检索的算法为首先按照B+Tree搜索算法搜索索引，如果指定的Key存在，则取出其data域的值，然后以data域的值为地址，读取相应数据记录。

　　MyISAM的索引方式也叫做“非聚集”的，之所以这么称呼是为了与InnoDB的聚集索引区分。

2、  InnoDB中的B+树

　　InnoDB中主键索引的叶子节点的数据区域存储的是数据记录，辅助索引存储的是主键值。

　　主键索引

　　

　　辅助索引：

　　

　　Innodb中的主键索引和实际数据时绑定在一起的，叶节点包含了完整的数据记录，这种索引叫做聚集索引。

　　也就是说Innodb的一个表一定要有主键，如果一个表在创建的时候没有显示定义主键，则Innodb会按照以下两种方式选择或者创建主键：

　　　　（1）判断表中有没有非空的唯一索引，如果有则选择建表时第一个定义的非空唯一索引作为主键，注意的定义非空唯一索引的顺序，而不是建表时列的顺序。

　　　　（2）如果连唯一索引也没有，则会默认建立一个隐藏的主键索引（用户不可见,这个字段长度为6个字节，类型为长整形）。

　　另外，Innodb的主键索引要比MyISAM的主键索引查询效率要高（少一次磁盘IO），并且比辅助索引也要高很多。所以，我们在使用Innodb作为存储引擎时，我们最好：

1. 1.  手动建立主键索引

   2.  尽量利用主键索引查询

　　在使用辅助索引查询时，会先定位到主键值，然后在根据主键索引查询。

　　针对Innodb数据库引擎：

　　select * from tab where id = 14；

　　这样的条件查找主键，则直接搜索主键索引查找到对应的叶节点，因此可以直接获得行数据。

　　select * from tab where name = "zhangsan"；

　　对 Name 列进行条件搜索，则需要两个步骤：
　　　　1、第一步在辅助索引B+ 树中检索Name，到达其叶子节点获取对应的主键值。
　　　　2、第二步根据主键值在主索引B+树中再执行一次 B+ 树检索操作，最终到达叶子节点即可获取整行数据。
　　　　上面这个过程称为回表。

　　

　　知道了InnoDB的索引实现后，就很容易明白为什么不建议使用过长的字段作为主键，因为所有辅助索引都引用主索引，过长的主键会令辅助索引变得过大。再例如，用非单调（非自增）的字段作为主键在InnoDB中不是个好主意，因为InnoDB数据文件本身是一颗B+Tree，非单调的主键会造成在插入新记录时数据文件为了维持B+Tree的特性而频繁的分裂调整，十分低效，而使用自增字段作为主键则是一个很好的选择。

五  为什么一个节点为1页（16k）就够了？

　　对着上面Mysql中Innodb中对B+树的实际应用（主要看主键索引），可以发现B+树中的一个节点存储的内容是：

• • 非叶子节点：主键+指针

  • 叶子节点：行数据

　　那么，假设我们一行数据大小为1K，那么一页就能存16条数据，也就是一个叶子节点能存16条数据；

　　再看非叶子节点，假设主键ID为bigint类型，那么长度为8B，指针大小在Innodb源码中为6B，一共就是14B，那么一页里就可以存储16K/14=1170个(主键+指针)，那么一颗高度为2的B+树能存储的数据为：1170*16=18720条，一颗高度为3的B+树能存储的数据为：1170*1170*16=21902400（千万级条）。

　　所以在InnoDB中B+树高度一般为1-3层，它就能满足千万级的数据存储。在查找数据时一次页的查找代表一次IO，所以通过主键索引查询通常只需要1-3次IO操作即可查找到数据。

　　所以也就回答了我们的问题，1页=16k这么设置是比较合适的，是适用大多数的企业的，当然这个值是可以修改的，所以也能根据业务的时间情况进行调整。

六  索引使用策略及优化

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

1  Explain

　　当Explain 与 SQL语句一起使用时，MySQL 会显示来自优化器关于SQL执行的信息。也就是说，MySQL解释了它将如何处理该语句，包括如何连接表以及什么顺序连接表等。

 

　　Explain 执行计划包含字段信息如下：分别是 id、select_type、table、partitions、type、possible_keys、key、key_len、ref、rows、filtered、Extra 12个字段。

　　具体每个字段的含义可以参考：https://juejin.im/post/5ec4e4a5e51d45786973b357

　　在explain执行结果中，rows统计的行数只是一个接近的数字，不是完全正确的，索引也不一定就是走最优的，是可能走错的。

　　MySQL中数据的单位都是页，MySQL又采用了采样统计的方法，采样统计的时候，InnoDB默认会选择N个数据页，统计这些页面上的不同值，得到一个平均值，然后乘以这个索引的页面数，就得到了这个索引的基数。

　　我们数据是一直在变的，所以索引的统计信息也是会变的，会根据一个阈值，重新做统计。

　　至于MySQL索引可能走错也很好理解，如果走A索引要扫描100行，B所有只要20行，但是他可能选择走A索引，你可能会想MySQL是不是有病啊，其实不是的。

　　一般走错都是因为优化器在选择的时候发现，走A索引没有额外的代价，比如走B索引并不能直接拿到我们的值，还需要回到主键索引才可以拿到，多了一次回表的过程，这个也是会被优化器考虑进去的。他发现走A索引不需要回表，没有额外的开销，所有他选错了。

　　如果是上面的统计信息错了，那简单，我们用analyze table tablename 就可以重新统计索引信息了，所以在实践中，如果你发现explain的结果预估的rows值跟实际情况差距比较大，可以采用这个方法来处理。

　　如果是索引选错了，一个方法就是force index强制走正确的索引，或者优化SQL，最后实在不行，可以新建索引，或者删掉错误的索引。

2  使用覆盖索引

　　由于根据辅助索引进行搜索时，需要先搜索辅助索引获取主键值，再搜索主键索引才能得到行数据，而如果索引已经包含了所有满足查询需要的数据，这时就不再需要回表操作。因此优化的目的是：直接通过辅助索引即可获取需要的数据。

　　在上面的SQL中，我们查询的是 select *，如果是根据 Name 查询 Id 呢？即 select Id from tab where Name='Jobs'。

　　很明显，由于辅助索引 Name 上已经存储了 Id 的值，所以这时，查询便不会再次回表查询。

　　如果索引已经包含了所有满足查询需要的数据，这时我们称之为覆盖索引（Covering Index），这时就不再需要回表操作。

　　如下SQL：

　　select itemId from itemCenter where size between 1 and 6

 

　　

　　因为商品id itemId一般都是主键，在size索引上肯定会有我们这个值，这个时候就不需要回主键表去查询id信息了。由于覆盖索引可以减少树的搜索次数，显著提升查询性能，所以使用覆盖索引是一个常用的性能优化手段。

　　只需要读取索引而不用读取数据有以下一些优点：

　　　　1、索引条目通常远小于数据行大小，只需要读取索引，则 MySQL 会极大地减少数据访问量。

　　　　2、因为索引是按照列值顺序存储的，所以对于 IO 密集的范围查找会比随机从磁盘读取每一行数据的 IO 少很多。

　　　　3、覆盖索引对 InnoDB 表特别有用。因为 InnoDB 的辅助索引在叶子节点中保存了行的主键值，所以如果二级主键能够覆盖查询，则可以避免对主键索引的二次查询；

　　　　由于覆盖索引可以减少树的搜索次数，显著提升查询性能。

　　不是所有类型的索引都可以成为覆盖索引。覆盖索引必须要存储索引的列，而哈希索引、空间索引和全文索引等都不存储索引列的值，所以MySQL只能使用B+Tree索引做覆盖索引。

　　当发起一个被索引覆盖的查询(也叫作索引覆盖查询)时，在EXPLAIN的Extra列可以看到 “Using index” 的信息：

　　　　　　

　　Using where：表示优化器需要通过索引回表查询数据；

　　Using index：表示直接访问索引就足够获取到所需要的数据，不需要通过索引回表；

　　Using index condition：在5.6版本后加入的新特性（Index Condition Pushdown：ICP 索引条件下沉）;Using index condition 会先条件过滤索引，过滤完索引后找到所有符合索引条件的数据行，随后用 WHERE 子句中的其他条件去过滤这些数据行；

　　Using where && Using index：这个确实不了解它和 Using index condition 的区别。

3  无where条件查询优化

　　 

 　　staff_id列上目前没有索引，在执行计划中，type 为ALL，表示进行了全表扫描，此时对staff_id建立索引，如下：

　　ALERT TABLE t1 ADD KEY(staff_id);

　　explain select sql_no_cache count(staff_id) from t1\G
　　*************************** 1. row ***************************
           　　id: 1
  　　select_type: SIMPLE
        　　table: t1
         　　type: index
　　possible_keys: NULL
          　　key: staff_id
      　　key_len: 1
          　　ref: NULL
         　　rows: 1023849
　　　　　 　　Extra: Using index


　　1 row in set (0.00 sec)

　　从执行计划中可以看出，possible_key: NULL，说明没有WHERE条件时查询优化器无法通过索引检索数据，这里使用了索引的另外一个优点，即从索引中获取数据，减少了读取的数据块的数量。 无where条件的查询，可以通过索引来实现索引覆盖查询，但前提条件是，查询返回的字段数足够少，更不用说select *之类的了。毕竟，建立key length过长的索引，始终不是一件好事情。

4  使用组合索引（联合索引）

　　　　组合索引，由两个或多个列的索引。它规定了 MySQL 从左到右地使用索引字段，对字段的顺序有一定要求，即最左匹配原则。

　　　　例如：

　　　　如果有一个 3 列索引 (col1,col2,col3)，则相当于已经对 (col1)、(col1,col2)、(col1,col2,col3) 上建立了索引；但是 (col2,col3) 上并没有。

　　　　如果有一个 2 列的索引 (col1,col2)，则相当于已经对 (col1)、(col1,col2) 上建立了索引；

　　　　　　　　　

　　　　如上图索引，键值都是排序的，通过叶子节点可以逻辑上顺序的读出所有数据。

　　　　数据（1,1）（1,2）（2,1）（2,4）（3,1）（3,2）是按照（a，b）先比较 a 再比较 b 的顺序排列。

　　　　所以从全局看，a 是全局有序的，而 b 则不是。

　　　　基于上面的结构，对于以下查询显然是可以使用（a，b）这个联合索引的：

　　　　select * from table where a=xxx and b=xxx ;
　　　　select * from table where a=xxx;

　　　　但是对于下面的 sql 是不能使用这个联合索引的，因为叶子节点的 b 值，1,2,1,4,1,2 显然不是排序的。　　　

　　　　select * from table where b=xxx

　　只要满足最左前缀，就可以利用索引来加速检索。这个最左前缀可以是联合索引的最左 N 个字段，也可以是字符串索引的最左 M 个字符。

注意：

　　1、主键字段其实跟所有非主键索引建立了联合索引，只是说如果主键字段没有在联合索引中明确声明，只会在其他索引中处于最右边；

　　2、最左前缀匹配原则，MySQL 会一直向右匹配直到遇到范围查询（>、<、between、like）就停止匹配。

　　比如 a = 1 and b = 2 and c > 3 and d = 4 如果建立 (a,b,c,d) 顺序的索引，d 是用不到索引的，如果建立 (a,b,d,c) 的索引，则都可以用到，a,b,d 的顺序可以任意调整。

　　3、= 和 in 的条件可以乱序

　　MySQL 的查询优化器会帮你优化成索引可以识别的形式。MySQL 查询优化器会判断纠正 SQL 语句该以什么样的顺序执行效率最高，最后才生成真正的执行计划。

为什么要使用联合索引？

　　1、 减少开销

　　　　"一个顶三个"。建一个联合索 引(col1,col2,col3)，实际相当于建了 (col1),(col1,col2),(col1,col2,col3) 三个索引。

　　　　每多一个索引，都会增加写操作的开销和磁盘空间的开销。对于大量数据的表，使用联合索引会大大的减少开销！

　　2、 覆盖索引

　　　　对联合索引 (col1,col2,col3)，如果有如下的sql: select col1,col2,col3 from test where col1=1 and col2=2。那么 MySQL 可以直接通过遍历索引取得数据，而无需回表，这减少了很多的随机 IO 操作。

　　　　减少 io 操作，特别的随机 io 其实是 dba 主要的优化策略。所以，在真正的实际应用中，覆盖索引是主要的提升性能的优化手段之一。

　　3、 效率高

　　　　索引列越多，通过索引筛选出的数据越少。

　　　　有 1000W 条数据的表，有如下sql: select col1,col2,col3 from table where col1=1 and col2=2 and col3=3，假设假设每个条件可以筛选出 10% 的数据。

　　　　如果只有单值索引，那么通过该索引能筛选出 1000W_10%=100w 条数据，然后再回表从 100w 条数据中找到符合 col2=2 and col3= 3 的数据，然后再排序，再分页；

　　　　如果是联合索引，通过索引筛选出 1000w_10% * 10% *10%=1w，效率提升可想而知！

（3）最左前缀原理与相关优化

　　高效使用索引的首要条件是知道什么样的查询会使用到索引，这个问题和B+Tree中的“最左前缀原理”有关，下面通过例子说明最左前缀原理。

　　这里先说一下联合索引（组合索引）的概念。在上文中，我们都是假设索引只引用了单个的列，实际上，MySQL中的索引可以以一定顺序引用多个列，这种索引叫做联合索引，一般的，一个联合索引是一个有序元组<a1, a2, …, an>，其中各个元素均为数据表的一列。另外，单列索引可以看成联合索引元素数为1的特例。

　　以employees.titles表为例，下面先查看其上都有哪些索引：

　　

　　从结果中可以到titles表的主索引为<emp_no, title, from_date>，还有一个辅助索引<emp_no>。为了避免多个索引使事情变复杂（MySQL的SQL优化器在多索引时行为比较复杂），这里我们将辅助索引drop掉：

　　ALTER TABLE employees.titles DROP INDEX emp_no;

　　这样就可以专心分析索引PRIMARY的行为了。

　　情况一：全列匹配。

　　

　　很明显，当按照索引中所有列进行精确匹配（这里精确匹配指“=”或“IN”匹配）时，索引可以被用到。这里有一点需要注意，理论上索引对顺序是敏感的，但是由于MySQL的查询优化器会自动调整where子句的条件顺序以使用适合的索引，例如我们将where中的条件顺序颠倒：

　　

　　效果是一样的。

　　情况二：最左前缀匹配。

　　

　　当查询条件精确匹配索引的左边连续一个或几个列时，如<emp_no>或<emp_no, title>，所以可以被用到，但是只能用到一部分，即条件所组成的最左前缀。上面的查询从分析结果看用到了PRIMARY索引，但是key_len为4，说明只用到了索引的第一列前缀。

　　情况三：查询条件用到了索引中列的精确匹配，但是中间某个条件未提供。

　　

　　此时索引使用情况和情况二相同，因为title未提供，所以查询只用到了索引的第一列，而后面的from_date虽然也在索引中，但是由于title不存在而无法和左前缀连接，因此需要对结果进行扫描过滤from_date（这里由于emp_no唯一，所以不存在扫描）。

　　如果想让from_date也使用索引而不是where过滤，可以增加一个辅助索引<emp_no, from_date>，此时上面的查询会使用这个索引。除此之外，还可以使用一种称之为“隔离列”的优化方法，将emp_no与from_date之间的“坑”填上。

首先我们看下title一共有几种不同的值：

　　

只有7种。在这种成为“坑”的列值比较少的情况下，可以考虑用“IN”来填补这个“坑”从而形成最左前缀：

这次key_len为59，说明索引被用全了，但是从type和rows看出IN实际上执行了一个range查询，这里检查了7个key。看下两种查询的性能比较：

　　“填坑”后性能提升了一点。如果经过emp_no筛选后余下很多数据，则后者性能优势会更加明显。当然，如果title的值很多，用填坑就不合适了，必须建立辅助索引。

　　情况四：查询条件没有指定索引第一列。

　　由于不是最左前缀，索引这样的查询显然用不到索引。

　　情况五：匹配某列的前缀字符串。

　　此时可以用到索引，但是如果通配符不是只出现在末尾，则无法使用索引。（原文表述有误，如果通配符%不出现在开头，则可以用到索引，但根据具体情况不同可能只会用其中一个前缀）

　　情况六：范围查询。

　　范围列可以用到索引（必须是最左前缀），但是范围列后面的列无法用到索引。同时，索引最多用于一个范围列，因此如果查询条件中有两个范围列则无法全用到索引。

　　可以看到索引对第二个范围索引无能为力。这里特别要说明MySQL一个有意思的地方，那就是仅用explain可能无法区分范围索引和多值匹配，因为在type中这两者都显示为range。同时，用了“between”并不意味着就是范围查询，例如下面的查询：

　　看起来是用了两个范围查询，但作用于emp_no上的“BETWEEN”实际上相当于“IN”，也就是说emp_no实际是多值精确匹配。可以看到这个查询用到了索引全部三个列。因此在MySQL中要谨慎地区分多值匹配和范围匹配，否则会对MySQL的行为产生困惑。

　　情况七：查询条件中含有函数或表达式。

　　很不幸，如果查询条件中含有函数或表达式，则MySQL不会为这列使用索引（虽然某些在数学意义上可以使用）。例如：

　　虽然这个查询和情况五中功能相同，但是由于使用了函数left，则无法为title列应用索引，因为需要计算每一行数据的title列，而情况五中用LIKE则可以。再如：

　　显然这个查询等价于查询emp_no为10001的函数，但是由于查询条件是一个表达式，MySQL无法为其使用索引。看来MySQL还没有智能到自动优化常量表达式的程度，因此在写查询语句时尽量避免表达式出现在查询中，而是先手工进行代数运算，转换为无表达式的查询语句。

（4）索引选择性与前缀索引

　　既然索引可以加快查询速度，那么是不是只要是查询语句需要，就建上索引？答案是否定的。因为索引虽然加快了查询速度，但索引也是有代价的：索引文件本身要消耗存储空间，同时索引会加重插入、删除和修改记录时的负担，另外，MySQL在运行时也要消耗资源维护索引，因此索引并不是越多越好。一般两种情况下不建议建索引。

　　（1）第一种情况是表记录比较少，例如一两千条甚至只有几百条记录的表，没必要建索引，让查询做全表扫描就好了。至于多少条记录才算多，这个个人有个人的看法，我个人的经验是以2000作为分界线，记录数不超过 2000可以考虑不建索引，超过2000条可以酌情考虑索引。

　　（2）另一种不建议建索引的情况是索引的选择性较低。所谓索引的选择性（Selectivity），是指不重复的索引值（也叫基数，Cardinality）与表记录数（#T）的比值：

　　　　Index Selectivity = Cardinality / #T

　　显然选择性的取值范围为(0, 1]，选择性越高的索引价值越大，这是由B+Tree的性质决定的。例如，上文用到的employees.titles表，如果title字段经常被单独查询，是否需要建索引，我们看一下它的选择性：

　　title的选择性不足0.0001（精确值为0.00001579），所以实在没有什么必要为其单独建索引。

　　有一种与索引选择性有关的索引优化策略叫做前缀索引，就是用列的前缀代替整个列作为索引key，当前缀长度合适时，可以做到既使得前缀索引的选择性接近全列索引，同时因为索引key变短而减少了索引文件的大小和维护开销。下面以employees.employees表为例介绍前缀索引的选择和使用。

　　从图12可以看到employees表只有一个索引<emp_no>，那么如果我们想按名字搜索一个人，就只能全表扫描了：

　　如果频繁按名字搜索员工，这样显然效率很低，因此我们可以考虑建索引。有两种选择，建<first_name>或<first_name, last_name>，看下两个索引的选择性：

　　

　　<first_name>显然选择性太低，<first_name, last_name>选择性很好，但是first_name和last_name加起来长度为30，有没有兼顾长度和选择性的办法？可以考虑用first_name和last_name的前几个字符建立索引，例如<first_name, left(last_name, 3)>，看看其选择性：

　　

　　选择性还不错，但离0.9313还是有点距离，那么把last_name前缀加到4：

　　这时选择性已经很理想了，而这个索引的长度只有18，比<first_name, last_name>短了接近一半，我们把这个前缀索引 建上：

　　此时再执行一遍按名字查询，比较分析一下与建索引前的结果：

　　性能的提升是显著的，查询速度提高了120多倍。

　　前缀索引兼顾索引大小和查询速度，但是其缺点是不能用于ORDER BY和GROUP BY操作，也不能用于Covering index（即当索引本身包含查询所需全部数据时，不再访问数据文件本身）。

（5）InnoDB的主键选择与插入优化

　　在使用InnoDB存储引擎时，如果没有特别的需要，请永远使用一个与业务无关的自增字段作为主键。

　　上文讨论过InnoDB的索引实现，InnoDB使用聚集索引，数据记录本身被存于主索引（一颗B+Tree）的叶子节点上。这就要求同一个叶子节点内（大小为一个内存页或磁盘页）的各条数据记录按主键顺序存放，因此每当有一条新的记录插入时，MySQL会根据其主键将其插入适当的节点和位置，如果页面达到装载因子（InnoDB默认为15/16），则开辟一个新的页（节点）。

　　如果表使用自增主键，那么每次插入新的记录，记录就会顺序添加到当前索引节点的后续位置，当一页写满，就会自动开辟一个新的页。如下图所示：

　　

　　这样就会形成一个紧凑的索引结构，近似顺序填满。由于每次插入时也不需要移动已有数据，因此效率很高，也不会增加很多开销在维护索引上。

　　如果使用非自增主键（如果身份证号或学号等），由于每次插入主键的值近似于随机，因此每次新纪录都要被插到现有索引页得中间某个位置：

　　

　　此时MySQL不得不为了将新记录插到合适位置而移动数据，甚至目标页面可能已经被回写到磁盘上而从缓存中清掉，此时又要从磁盘上读回来，这增加了很多开销，同时频繁的移动、分页操作造成了大量的碎片，得到了不够紧凑的索引结构，后续不得不通过OPTIMIZE TABLE来重建表并优化填充页面。

　　因此，只要可以，请尽量在InnoDB上采用自增字段做主键。

七  索引条件下推 

1  索引条件下推介绍

　　索引条件下推（ICP：index condition pushdown）是 MySQL 中一个常用的优化，尤其是当 MySQL 需要从一张表里检索数据时。

　　ICP（index condition pushdown）是 MySQL 利用索引（二级索引）元组和筛字段在索引中的 WHERE 条件从表中提取数据记录的一种优化操作。

　　ICP 的思想是：存储引擎在访问索引的时候检查筛选字段在索引中的 where 条件，如果索引元组中的数据不满足推送的索引条件，那么就过滤掉该条数据记录。

　　ICP（优化器）尽可能的把 index condition 的处理从 server 层下推到存储引擎层。

　　存储引擎使用索引过滤不相关的数据，仅返回符合 index condition 条件的数据给 server 层。也是说数据过滤尽可能存储引擎层进行，而不是返回所有数据给 server 层，然后后再根据 where 条件进行过滤。

2  下推过程

（1）优化器没有使用 ICP 时

　　数据访问和提取的过程如下：

　　

　　①：MySQL Server 发出读取数据的命令，调用存储引擎的索引读或全表表读。此处进行的是索引读。

　　②、③：进入存储引擎，读取索引树，在索引树上查找，把满足条件的（红色的）从表记录中读出（步骤 ④，通常有 IO）。

　　⑤：从存储引擎返回标识的结果。

　　以上，不仅要在索引行进行索引读取（通常是内存中，速度快。步骤 ③），还要进行进行步骤 ④，通常有 IO。

　　⑥：从存储引擎返回查找到的多条数据给 MySQL Server，MySQL Server 在 ⑦ 得到较多的元组。

　　⑦--⑧：依据 WHERE 子句条件进行过滤，得到满足条件的数据。

　　注意在 MySQL Server 层得到较多数据，然后才过滤，最终得到的是少量的、符合条件的数据。

　　 

　　在不支持 ICP 的系统下，索引仅仅作为 data access 使用。

优化器使用ICP时

　　

　　①：MySQL Server 发出读取数据的命令，过程同图一。

　　②、③：进入存储引擎，读取索引树，在索引树上查找，把满足已经下推的条件的（红色的）从表记录中读出（步骤 ④，通常有 IO）；

　　⑤：从存储引擎返回标识的结果。

　　此处，不仅要在索引行进行索引读取（通常是内存中，速度快。步骤 ③），还要在 ③ 这个阶段依据下推的条件进行进行判断，不满足条件的，不去读取表中的数据，直接在索引树上进行下一个索引项的判断，直到有满足条件的，才进行步骤 ④ ，这样，较没有 ICP 的方式，IO 量减少。

　　⑥：从存储引擎返回查找到的少量数据给 MySQL Server，MySQL Server 在 ⑦ 得到少量的数据。

　　因此比较图一无 ICP 的方式，返回给 MySQL Server 层的即是少量的、 符合条件的数据。

　　 

　　在 ICP 优化开启时，在存储引擎端首先用索引过滤可以过滤的 where 条件，然后再用索引做 data access，被 index condition 过滤掉的数据不必读取，也不会返回 server 端。

　　比如：

SELECT * FROM employees WHERE first_name='Mary' AND last_name LIKE '%man';

　　在没有 ICP 时，首先通过索引前缀从存储引擎中读出所有 first_name 为 Mary 的记录，然后在 server 端用 where 筛选 last_name 的 like 条件；

　　而启用 ICP 后，由于 last_name 的 like 筛选可以通过索引字段进行，那么存储引擎内部通过索引与 where 条件的对比来筛选掉不符合 where 条件的记录，这个过程不需要读出整条记录，同时只返回给 server 筛选后条记录，因此提高了查询性能。

注意事项

　　有几个关于ICP的事情要注意：

• ICP 只能用于二级索引（辅助索引），不能用于主索引；

• 也不是全部 where 条件都可以用 ICP 筛选，如果某 where 条件的字段不在索引中，当然还是要读取整条记录做筛选，在这种情况下，仍然要到 server 端做 where 筛选；

• ICP 的加速效果取决于在存储引擎内通过 ICP 筛选掉的数据的比例；

八  总结

　　1、最左前缀匹配原则，非常重要的原则，MySQL 会一直向右匹配直到遇到范围查询 （>、<、between、like）就停止匹配；

　　2、= 和 in 的条件可以乱序；

　　3、尽量选择区分度高的列作为索引，区分度表示字段不重复的比例，比例越大我们扫描的记录数越少；

　　4、索引列不能参与计算，保持列「干净」。原因很简单，b+ 树中存的都是数据表中的字段值，但进行检索时，需要把所有元素都应用函数才能比较，显然成本太大。

　　5、尽量的扩展索引，不要新建索引。

　　6、列类型尽量定义成数值类型，且长度尽可能短，如主键和外键，类型字段等等 

　　7、建立单列索引

　　8、根据需要建立多列联合索引

　　　　当单个列过滤之后还有很多数据，那么索引的效率将会比较低，即列的区分度较低

　　　　如果在多个列上建立索引，那么多个列的区分度就大多了，将会有显著的效率提高。

　　　　根据业务场景建立覆盖索引只查询业务需要的字段，如果这些字段被索引覆盖，将极大的提高查询效率

　　9、多表连接的字段上需要建立索引，这样可以极大提高表连接的效率

　　10、where条件字段上需要建立索引

　　11、排序字段上需要建立索引

　　12、分组字段上需要建立索引

　　13、Where条件上不要使用运算函数，以免索引失效

索引是最好的解决方案吗？

　　索引不是最好的，但已经是相当好的了。

　　当表非常小时，没必要使用索引，直接全表查询好了；

　　当表是中大型时，比较适合使用索引，来快速定位目标数据；

　　当表是超大型时，创建和维护索引都是不小的代价，需要专业的 DBA 来分析，这种情况下可以尝试使用分表技术；

 

参考

　　　　MySQL常见的面试题＋索引原理分析！　　https://mp.weixin.qq.com/s/eG5KIp-mOMQCis_pDvCN_w

　　　　MySQL索引背后的数据结构及算法原理　　http://blog.codinglabs.org/articles/theory-of-mysql-index.html

　　　　如何设计高性能的索引？　　https://mp.weixin.qq.com/s?__biz=MjM5NjMyMjUzNg==&mid=2448131788&idx=1&sn=324b38feb96c00d43e706a5f9e07ca00&chksm=b2f42b4b8583a25d5b8fc92b35672c0eb75e7f9e80fbd10440eb2b0e38ffaeea1bb9f54e2133&scene=21#wechat_redirect　

　　　　索引的实现原理　　https://blog.csdn.net/timer_gao/article/details/78013826

　　　　Mysql 索引精讲　　https://juejin.im/post/5ccfdb05e51d453b7f0a0d4f

　　　　覆盖索引　　https://www.cnblogs.com/happyflyingpig/p/7662881.html