1
索引概念、索引模型
我们是怎么聊到索引的呢,是因为我提到我们的业务量比较大,每天大概有几百万的新数据生成,于是有了以下对话:
Q:你们每天这么大的数据量,都是保存在关系型数据库中吗?
A:是的,我们线上使用的是MySQL数据库
Q:每天几百万数据,一个月就是几千万了,那你们有没有对于查询做一些优化呢?
A:我们在数据库中创建了一些索引
-------
Q:那你能说说什么是索引吗?
A:索引其实是一种数据结构,能够帮助我们快速的检索数据库中的数据
Q:那么索引具体采用的哪种数据结构呢?
A:常见的MySQL主要有两种结构:Hash索引和B+ Tree索引,我们使用的是InnoDB引擎,默认的是B+树
------
Q:既然你提到InnoDB使用的B+ 树的索引模型,那么你知道为什么采用B+ 树吗?这和Hash索引比较起来有什么优缺点吗?
A:因为Hash索引底层是哈希表,哈希表是一种以key-value存储数据的结构,所以多个数据在存储关系上是完全没有任何顺序关系的,所以,对于区间查询是无法直接通过索引查询的,就需要全表扫描。所以,哈希索引只适用于等值查询的场景。而B+ 树是一种多路平衡查询树,所以他的节点是天然有序的(左子节点小于父节点、父节点小于右子节点),所以对于范围查询的时候不需要做全表扫描
Q:除了上面这个范围查询的,你还能说出其他的一些区别吗?
A:
B+ Tree索引和Hash索引区别?
哈希索引适合等值查询,但是无法进行范围查询
哈希索引没办法利用索引完成排序
哈希索引不支持多列联合索引的最左匹配规则
如果有大量重复键值的情况下,哈希索引的效率会很低,因为存在哈希碰撞问题
2
聚簇索引、覆盖索引
Q:刚刚我们聊到B+ Tree ,那你知道B+ Tree的叶子节点都可以存哪些东西吗?
A:InnoDB的B+ Tree可能存储的是整行数据,也有可能是主键的值
Q:那这两者有什么区别吗?
A:在 InnoDB 里,索引B+ Tree的叶子节点存储了整行数据的是主键索引,也被称之为聚簇索引。而索引B+ Tree的叶子节点存储了主键的值的是非主键索引,也被称之为非聚簇索引
Q:那么,聚簇索引和非聚簇索引,在查询数据的时候有区别吗?
A:聚簇索引查询会更快?
Q:为什么呢?
A:因为主键索引树的叶子节点直接就是我们要查询的整行数据了。而非主键索引的叶子节点是主键的值,查到主键的值以后,还需要再通过主键的值再进行一次查询
Q:刚刚你提到主键索引查询只会查一次,而非主键索引需要回表查询多次。(后来我才知道,原来这个过程叫做回表)是所有情况都是这样的吗?非主键索引一定会查询多次吗?
A:通过覆盖索引也可以只查询一次
覆盖索引?
覆盖索引(covering index)指一个查询语句的执行只用从索引中就能够取得,不必从数据表中读取。也可以称之为实现了索引覆盖。
当一条查询语句符合覆盖索引条件时,MySQL只需要通过索引就可以返回查询所需要的数据,这样避免了查到索引后再返回表操作,减少I/O提高效率。
如,表covering_index_sample中有一个普通索引 idx_key1_key2(key1,key2)。
当我们通过SQL语句:select key2 from covering_index_sample where key1 = 'keytest';的时候,就可以通过覆盖索引查询,无需回表。
3
联合索引、最左前缀匹配
Q:不知道的话没关系,想问一下,你们在创建索引的时候都会考虑哪些因素呢?
A:我们一般对于查询概率比较高,经常作为where条件的字段设置索引
Q: 那你们有用过联合索引吗?
A:用过呀,我们有对一些表中创建过联合索引
Q:那你们在创建联合索引的时候,需要做联合索引多个字段之间顺序你们是如何选择的呢?
A:我们把识别度最高的字段放到最前面
Q:为什么这么做呢?
A:这样的话可能命中率会高一点吧。。。
Q: 那你知道最左前缀匹配吗?
A:在创建多列索引时,我们根据业务需求,where子句中使用最频繁的一列放在最左边,因为MySQL索引查询会遵循最左前缀匹配的原则,即最左优先,在检索数据时从联合索引的最左边开始匹配。所以当我们创建一个联合索引的时候,如(key1,key2,key3),相当于创建了(key1)、(key1,key2)和(key1,key2,key3)三个索引,这就是最左匹配原则
4
索引下推、查询优化
Q:你们线上用的MySQL是哪个版本啊呢?
A:我们MySQL是5.7
Q:那你知道在MySQL 5.6中,对索引做了哪些优化吗?
A:有一个比较重要的 :Index Condition Pushdown Optimization
Index Condition Pushdown(索引下推)
MySQL 5.6引入了索引下推优化,默认开启,使用SET optimizer_switch = 'index_condition_pushdown=off';可以将其关闭。官方文档中给的例子和解释如下:
people表中(zipcode,lastname,firstname)构成一个索引
SELECT * FROM people WHERE zipcode='95054' AND lastname LIKE '%etrunia%' AND address LIKE '%Main Street%';
如果没有使用索引下推技术,则MySQL会通过zipcode='95054'从存储引擎中查询对应的数据,返回到MySQL服务端,然后MySQL服务端基于lastname LIKE '%etrunia%'和address LIKE '%Main Street%'来判断数据是否符合条件。
如果使用了索引下推技术,则MYSQL首先会返回符合zipcode='95054'的索引,然后根据lastname LIKE '%etrunia%'和address LIKE '%Main Street%'来判断索引是否符合条件。如果符合条件,则根据该索引来定位对应的数据,如果不符合,则直接reject掉。有了索引下推优化,可以在有like条件查询的情况下,减少回表次数。
Q:你们创建的那么多索引,到底有没有生效,或者说你们的SQL语句有没有使用索引查询你们有统计过吗?
A:这个还没有统计过,除非遇到慢SQL的时候我们才会去排查
Q:那排查的时候,有什么手段可以知道有没有走索引查询呢?
A:可以通过explain查看sql语句的执行计划,通过执行计划来分析索引使用情况
Q:那什么情况下会发生明明创建了索引,但是执行的时候并没有通过索引呢?
A:根据查询优化器计算出成本最低的方案,若是方案中并未使用索引,那么就会导致执行的时候并没有使用索引。
查询优化器?
一条SQL语句的查询,可以有不同的执行方案,至于最终选择哪种方案,需要通过优化器进行选择,选择执行成本最低的方案。
在一条单表查询语句真正执行之前,MySQL的查询优化器会找出执行该语句所有可能使用的方案,对比之后找出成本最低的方案。
这个成本最低的方案就是所谓的执行计划。优化过程大致如下:
1、根据搜索条件,找出所有可能使用的索引
2、计算全表扫描的代价
3、计算使用不同索引执行查询的代价
4、对比各种执行方案的代价,找出成本最低的那一个