MySQL查询计划 key_len计算方法

本文首先介绍了MySQL的查询计划中ken_len的含义；然后介绍了key_len的计算方法；最后通过一个伪造的例子,来说明如何通过key_len来查看联合索引有多少列被使用。

key_len的含义

在MySQL中,可以通过explain查看SQL语句所走的路径,如下所示：

其中,key_len表示使用的索引长度,是以字节为单位。在上面的例子中,由于int型占用4个字节,而索引中只包含了1列,所以,key_len是4。

下面是联合索引的情况：

联合索引ix包含了2列,并且都使用到了,所以,这里ken_len是8。

到这里,我们已经可以理解key_len的含义了,似乎已经没有什么可讲的了,但是,MySQL中key_len的计算还有很多需要注意的地方。

例如,我们将b这一列的NOT NULL约束去掉,然后ken_len就和我们预期不一样了,如下所示：

MySQL中,key_len的计算规则如下：

1.如果列可以为空,则在数据类型占用字节的基础上加1,如int型,不能为空key_len为4,可以为空key_len为5

2.如果列是字符型,则还需要考虑字符集,如某列的定义是char(10),且是utf8,不能为空,则key_len为10 * 3 ,可以为空则key_len为10*3+1
3.如果列是变长的,则在数据列所占字节的基数上再加2,如varchar(10),不能为空,则key_len为10*3 + 2 ,可以为空则key_len为10*3+2+1
此外,decimal列的计算方法与上面一样,如果可以为空,则在数据类型占用字节的基础上加1,但是,decimal本身所占用字节数,计算就比较复杂。

根据官方文档可以知道,decimal定义为decimal(M,D),其中,M是总的位数,D是小数点后保留的位数。小数点前与小数点后的数字分开存储,且以9位数为1组,用4个字节保存,如果低于9位数,需要的字节数如下：

Leftover Digits Number of Bytes
-----------------------------
|0 |0 |
|1-2 |1 |
|3-4 |2 |
|5-6 |3 |
|7-9 |4 |
-----------------------------

例如：
•decimal(20,6)=> 小数点左边14位,小数点右边6位 => 小数点左边分组为5 + 9,需要3个字节+4个字节存储,小数点右边一个分组,需要3个字节存储 => 总共需要10个字节
•decimal(18,9)=> 小数点左边9位数,小数点右边9位数 => 分别使用4个字节存储 => 共需要 8个字节
•decimal(18,2)=> 小数点左边16位数,小数点右边2位数 => 分组为7 + 9,需要8个字节存储,小数点右边1个字节存储 => 共需要9个字节

通过key_len分析联合索引

如下所示,我们定义了一个表t,表t包含a、b、c、d共4列：

mysql> show create table t\G
*************************** 1. row ***************************
Table: t
Create Table: CREATE TABLE `t` (
`a` int(11) NOT NULL,
`b` int(11) DEFAULT NULL,
`c` int(11) DEFAULT NULL,
`d` int(11) DEFAULT NULL,
PRIMARY KEY (`a`),
KEY `ix_x` (`b`,`d`,`c`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

现在要执行SQL语句如下：

select a from t where b = 5 and d = 10 order by c;

假设我们有一个索引ix_x(b,d,c),通过explain得到如下输出：

mysql> explain select a from t where b = 5 and d = 10 order by c;
+----+-------------+-------+------+---------------+------+---------+-------------+------+--------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+-------------+------+--------------------------+
| 1 | SIMPLE | t | ref | ix_x | ix_x | 10 | const,const | 1 | Using where; Using index |
+----+-------------+-------+------+---------------+------+---------+-------------+------+--------------------------+
1 row in set (0.00 sec)

可以看到,查询语句使用了联合索引中的b和d两列来过滤数据。

--注意：key_len是表示得到结果集所使用的选择的索引的长度，但不包括order by,也就是说，如果order by也使用了索引则key_len则不计算在内。

如果我们定义的联合索引不是`ix_x(b,d,c)`,而是`ix_x(b, c, d)`,通过explain得到的输入如下：

mysql> alter table t drop index ix_x;
mysql> alter table t add index ix_x(b, c, d);
mysql> explain select a from t where b = 5 and d = 10 order by c;
+----+-------------+-------+------+---------------+------+---------+-------+------+--------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+-------+------+--------------------------+
| 1 | SIMPLE | t | ref | ix_x | ix_x | 5 | const | 2 | Using where; Using index |
+----+-------------+-------+------+---------------+------+---------+-------+------+--------------------------+
1 row in set (0.00 sec)

key_len为5,也就是说,只用到了联合索引中的第一列,可以看到,虽然联合索引包含了我们要查询的所有列,但是,由于定义的顺序问题,SQL语句并不能够充分利用索引。

http://www.newfreesoft.com/database/mysql_query_plan_key_len_know_all_5408/

原文:如何构建高性能MySQL索引

介绍

如何分析一个索引是不是好索引，以及如何构建一个好的索引。

索引误区

多列索引

一个索引的常见误区是为每一列创建一个索引，如下面创建的索引：

CREATE TABLE `t` (
  `c1` varchar(50) DEFAULT NULL,
  `c2` varchar(50) DEFAULT NULL,
  `c3` varchar(50) DEFAULT NULL,
  KEY `c1` (`c1`),
  KEY `c2` (`c2`),
  KEY `c3` (`c3`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

t表里有三列，并且为每列创建了一个索引。创建索引的人为了能够快速访问表中的任何一列，因此为每一列添加了一个单独的索引。在多个列上创建索引通常并不能很好的提高MySQL查询性能，虽然说MySQL 5.0之后引入了索引合并策略，可以将多个单列索引合并成一个索引，但这并不总是有效的。同时创建多个索引的时候还会增加数据插入的成本，在插入数据的时候需要同时维护多个索引的写入操作。

索引的计算

看下面这条sql语句：

select name from student where id + 1 = 5

即使我们在student表的id列上建立索引，上面的这条SQL语句也无法使用索引。SQL语句中索引字段不能是表达式的一部分，也不能是函数的参数。

索引的长度以及选择性

尽量不要在一个很长的列上使用索引，否则会导致索引占用的空间很大，同时在进行数据的插入和更新的时候意味着更慢的速度。因此使用uuid列作为索引并不是一个好的选择。从上一篇文章中我们可以知道，为了加快数据的访问索引是需要常驻内存的，假如说我们把64位uuid作为索引，那么随着表中数据量的增加索引的大小也在急剧增加。同时因为uuid并没有顺序性，因此在数据插入的时候都需要从根节点找到当前索引的插入位置，如果同一个节点中的索引大小达到上限，还会导致节点分裂，更加降低了插入速度。
创建索引另外一个需要考虑的是索引的选择性，通常情况下我们会使用选择性高的列作为索引，但是也不一定一直是这样，下一节会介绍如何权衡索引的选择性。

创建高性能索引

选择正确的索引顺序

在选择索引的顺序的时候有一个原则：将索引选择性最高的列放在左侧，同时索引的顺序要与查询索引的顺序一致，并且要兼顾考虑排序和分组的需要。在一个多列B树多列中索引的顺序意味着索引首先按照最左侧的列进行排序，其次是第二列。所以无论是where语句还是order by语句都需要尽量满足这个顺序，这样才能更好的使用索引。

索引的选择性

列的选择性高的含义是通过这一列能够更多的过滤掉无用的数据，举个极端的例子，如果把自增id建成索引那么它的选择性是最高的，因为会把无用的数据都过滤掉，只会剩下一条有效数据。我们可以通过下面的方式来简单衡量某一个列的选择性：

select count(distinct columnA)/count(*) as selectivity from table

当上面的数据越大的时候意味着columnA的选择性越高。这种方式提供了一个衡量平均选择性的办法，但是也不一定是有效的，需要具体情况具体分析。

前缀索引

当遇到特别长的列，但又必须要建立索引的时候可以考虑建立前缀索引。前缀索引的含义是把某一列的前N个字符作为索引，创建前缀索引的方式如下：

alter table test add key(columnA(5));

上面这个语句就是把columnA的前5个字符创建为前缀索引。前缀索引是一种使索引更小、更快的有效办法。但是前缀所有有一个缺点：MySQL无法使用前缀索引来做order by和group by，也无法使用前缀索引做覆盖扫描。

聚簇索引和非聚簇索引

聚簇索引

    聚簇索引代表一种数据的存储方式，表示同一个结构中保存了B-Tree索引和数据行。也就是说当建立聚簇索引的时候实际的数据行存放在索引的叶子节点上。这也决定了每个表只能有一个聚簇索引。
聚簇索引组织数据的方式如下图所示：

    从图中可以看到索引的叶子节点和数据行是存放在一起的，这样的好处是可以直接读取到数据行。在创建表的时候如果我们不显式指定聚簇索引，那么MySQL将会按照下面的逻辑来选择聚簇索引：首先会通过主键列来聚集数据，如果没有主键列那么会选择唯一的非空索引来替代。如果还没有这样的索引那么会隐式的创建一个主键列来作为聚簇索引。
    聚簇索引优点：
1、相关数据存放在一起，检索的时候降低IO的次数
2、数据访问更快
3、使用覆盖索引扫描的查询可以直接使用节点中的主键值
    在使用上面的优点的时候聚簇索引也有一定的缺点：
1、聚簇索引将数据聚集在一起限制了插入速度，插入速度比较依赖于主键的顺序
2、更新索引的时候代价会变高
3、二级索引的访问的时候需要查找两次

非聚簇索引

非聚簇索引通常被称为二级索引，与聚簇索引的不同在于，非聚簇索引的叶子节点存放的是数据的行指针或者是一个主键值。这样在查找数据的时候首先定位到叶子节点上的主键值(或者行指针)，然后通过主键值再到聚簇索引中查找到对应的数据。从中我们可以看到对于非聚簇索引的查询需要走两次索引。下图是一个非聚簇索引：

这个索引是InnoDB中的耳机索引，叶子节点中存储的是索引和主键。对于MyISAM叶子节点存储的是索引和行指针。

覆盖索引

如果一个索引包含或者说覆盖所有需要查询的字段的值，那么就称为覆盖索引。覆盖索引可以极大的提高查询的效率，如果我们的查询中只查询索引，而不用去回表那应该最好不过了。
通常我们使用explain关键字来查看一个查询语句的执行计划，通过执行计划我们可以了解到查询的细节。如果是覆盖索引，我们会看到执行计划的Extra列里有”Using Index”的信息。在查询语句中一般我们希望是where条件中的语句尽量能被覆盖，并且顺序要跟索引的保持一致。还有一个需要注意的点是MySQL不能在索引中使用like操作，这样会导致后面的索引失效。

后记

本文主要讲了几种索引的原理以及如何构建一个高性能的索引。索引的优先是一个渐进的过程，随着数据量和查询语句的不同而发生变化，重要的是了解索引的原理，这样做出正确的优化。下一篇文章中将会介绍explain关键字，教你如何来看执行计划，以及如何判断一个查询语句是否需要优化的。

posted @ 2018-12-27 10:35 海东潮阅读(1392) 评论(0) 编辑收藏举报

数据库技术和故事

从今以后，愿你无所畏惧。