一个索引的常见误区是为每一列创建一个索引,如下面创建的索引:
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,也无法使用前缀索引做覆盖扫描。
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,也无法使用前缀索引做覆盖扫描。