Mysql的复合索引,生效了吗?来篇总结文章

CodeRoverPro
• 阅读 1028

背景

最近频繁出现慢SQL导致系统性能问题,于是决定针对索引进行一些优化。一些表结构本身已经有了不少索引,如果再继续添加索引,势必会影响到插入数据的性能。那么,是否可以使用组合索引来达到目的呢?这篇文章咱们来一探究竟。

认识复合索引

如果where条件中使用到多个字段,并且需要对多个字段建立索引,此时就可以考虑采用复合索引(组合索引)。比如查询地址时需要输入省、市,那么在省、市上建立索引,当数据量大时会明显提高查询速度。

组合索引有啥优势呢?

  • 减少查询开销:建立复合索引(c1,c2,c3),实际上相当于建立了(c1),(c1,c2),(c1,c2,c3)三个索引。对于大表来说,可以极大减少开销。
  • 覆盖索引:MySQL可以直接通过遍历索引取得数据,而无需回表,减少了很多的随机io操作。
  • 效率高:索引列越多,通过索引筛选出来的数据就越少,从而提升查询效率。

缺点:

  • 索引字段越多,创建的索引越多,每个索引都会增加磁盘空间的开销;
  • 索引越多对查询效率提升越高,但对需要更新索引的增删改操作会有效率影响;

复合索引使用建议:单表最好不要超过1个复合索引,单个复合索引最好不超过3个字段。一旦超过,就需要考虑必要性和是否有其他替代方案。

最左匹配原则

复合索引遵从最左匹配原则,顾名思义,在组合索引中,最左侧的字段优先匹配。因此,在创建组合索引时,where子句中使用最频繁的字段放在组合索引的最左侧。

辅助索引是B+树实现的,虽然可以指定多个列,但是每个列的比较优先级不一样,写在前面的优先比较高。一旦出现遗漏,在B+树上就无法继续搜索了(通过补齐等措施解决的除外),因此是按照最左连续匹配来的。既然是在B+树上搜索,对于条件的比较自然是要求精确匹配(即"="和"IN")。

在where子句中用到两个字段c1和c2,那么创建索引时,两个字段的顺序应该是(c1,c2)还是(c2,c1)呢?

正确的做法是:把重复值最少的放前面。比如,95%的值都不重复,则可考虑放最前面。

字段顺序的影响

复合索引遵从最左匹配原则,那么在where查询条件中的字段是否也需要按照索引的顺序来写呢?

比如,复合索引为(c1,c2,c3),下面两个查询条件是否会对索引有影响呢?

select * from t_user where c1 = 1 and c2 = 4;
select * from t_user where c2 = 4 and c1 = 1;

看到有文章提出第一条SQL语句的效率更高,是否可信?两种查询方式条件一样,结果也应该一样,正常来说Mysql也会让它们走同样的索引。

通过Mysql的查询优化器explain分析上述两个条语句,会发现执行计划完全相同。也就是说:SQL语句中的字段顺序并不需要与复合索引字段顺序一致,查询优化器会自动调整顺序

如果说有效率影响,那么也就是查询优化器矫正顺序的影响吧,几乎可以忽略不计。

单字段是否可以触发索引?

对于复合索引为(c1,c2,c3),相当于(c1),(c1,c2),(c1,c2,c3)三个索引,如果查询条件中只有c1,很显然是会走索引的。

但如果where条件如下呢:

from t_user where c2 = 4;

上述语句是否会走索引呢?这得分几种情况来说明。

执行explan查询c1为条件的SQL语句:

explain select * from t_user where c1 = 1;

上述语句走的索引类型为:ref。ref类型表示Mysql会根据特定的算法快速查找到符合条件的索引,而不会对索引中每一个数据都进行扫描判断。这种类型的索引为了快速查出数据,索引就需要满足一定的数据结构。

执行explan查询c2为条件的SQL语句:

explain select c2 from t_user where c2 = 4;

上述语句走的索引类型为:index。index类型表示Mysql会对整个索引进行扫描,只要是索引或索引的一部分Mysql就可能会采用index方类型的方式扫描。由于此种方式是一条数据一条数据查找,性能并不高。

在这个例子中,对查询的字段有一定的要求,where中条件为c2,select中查询出的字段也只能是c2,才会走index类型的索引

如果将c2换成*或其他字段:

explain select * from t_user where c2 = 4;

上述语句会发现,不再走index索引,而是走全表扫描了。这也从侧面说明了Mysql为什么要讲最左匹配原则了。

所以结论是:如果单个字段为复合索引的首个字段,则会正常走索引;如果单个字段是复合索引的其他字段,且仅有该字段出现在select后面,则会走index类型索引;而其他情况,则走全表扫描

复合索引可以替代单一索引吗?

单一索引:(c1),复合索引:(c1,c2)。

当c1作为查询条件时,单一索引和复合索引查询速度几乎一样,甚至比复合索引还要略快。

如果仅用复合聚集索引的非起始列(c2)作为查询条件的话,复合索引是不起任何作用的。

对于一张表来说,如果有复合索引(c1,c2),则无需再建单一索引(c1)。

如果已经存在单一索引(c1),因查询所需,可添加复合索引(c1,c2)来提升效率。

小结

本篇文章整理了Mysql复合索引使用时所需注意的一些知识点,在使用时可以通过explain来查看一下你的SQL语句是否走了索引,走了什么索引。

但还要了解的是:Mysql的执行计划和查询的实际执行过程并不完全吻合。

别问我为什么知道,因为在实践中遇到过。同一条SQL语句,查询条件不同,有可能会走索引,也有可能不会走索引。

博主简介:《SpringBoot技术内幕》技术图书作者,酷爱钻研技术,写技术干货文章。

公众号:「程序新视界」,博主的公众号,欢迎关注~

技术交流:请联系博主微信号:zhuan2quan

点赞
收藏
评论区
推荐文章
blmius blmius
4年前
MySQL:[Err] 1292 - Incorrect datetime value: ‘0000-00-00 00:00:00‘ for column ‘CREATE_TIME‘ at row 1
文章目录问题用navicat导入数据时,报错:原因这是因为当前的MySQL不支持datetime为0的情况。解决修改sql\mode:sql\mode:SQLMode定义了MySQL应支持的SQL语法、数据校验等,这样可以更容易地在不同的环境中使用MySQL。全局s
Wesley13 Wesley13
3年前
MySQL部分从库上面因为大量的临时表tmp_table造成慢查询
背景描述Time:20190124T00:08:14.70572408:00User@Host:@Id:Schema:sentrymetaLast_errno:0Killed:0Query_time:0.315758Lock_
美凌格栋栋酱 美凌格栋栋酱
7个月前
Oracle 分组与拼接字符串同时使用
SELECTT.,ROWNUMIDFROM(SELECTT.EMPLID,T.NAME,T.BU,T.REALDEPART,T.FORMATDATE,SUM(T.S0)S0,MAX(UPDATETIME)CREATETIME,LISTAGG(TOCHAR(
添砖java的啾 添砖java的啾
4年前
distinct效率更高还是group by效率更高?
目录00结论01distinct的使用02groupby的使用03distinct和groupby原理04推荐groupby的原因00结论先说大致的结论(完整结论在文末):在语义相同,有索引的情况下groupby和distinct都能使用索引,效率相同。在语义相同,无索引的情况下:distinct效率高于groupby。原因是di
Wesley13 Wesley13
3年前
MySQL千万级别优化·中
MySQL千万级别的查询优化手段·中单列索引(假设在v\_record表中存在id列的索引)1、WHERE条件使用​EXPLAINSELECT\FROMv\_recordWHEREid2​结论:利用索引进行回表查询2、SELECT字段使用
Easter79 Easter79
3年前
Twitter的分布式自增ID算法snowflake (Java版)
概述分布式系统中,有一些需要使用全局唯一ID的场景,这种时候为了防止ID冲突可以使用36位的UUID,但是UUID有一些缺点,首先他相对比较长,另外UUID一般是无序的。有些时候我们希望能使用一种简单一些的ID,并且希望ID能够按照时间有序生成。而twitter的snowflake解决了这种需求,最初Twitter把存储系统从MySQL迁移
Wesley13 Wesley13
3年前
mysql设置时区
mysql设置时区mysql\_query("SETtime\_zone'8:00'")ordie('时区设置失败,请联系管理员!');中国在东8区所以加8方法二:selectcount(user\_id)asdevice,CONVERT\_TZ(FROM\_UNIXTIME(reg\_time),'08:00','0
Wesley13 Wesley13
3年前
MySQL索引的索引长度问题
MySQL的每个单表中所创建的索引长度是有限制的,且对不同存储引擎下的表有不同的限制。在MyISAM表中,创建组合索引时,创建的索引长度不能超过1000,注意这里索引的长度的计算是根据表字段设定的长度来标量的,例如:createtabletest(idint,name1varchar(300),name2varchar(300),nam
Wesley13 Wesley13
3年前
mysql5.6 分页查询优化
mysql5.6分页查询优化场景:表结构:主键(非自增)contentCode(varchar),过滤条件列为updateTime(timeStamp),已经为timestamp建立索引。搜索sql为:SELECTFROMmy_hello_tableWHEREupdat
Stella981 Stella981
3年前
ELK学习笔记之ElasticSearch的索引详解
0x00ElasticSearch的索引和MySQL的索引方式对比Elasticsearch是通过Lucene的倒排索引技术实现比关系型数据库更快的过滤。特别是它对多条件的过滤支持非常好,比如年龄在18和30之间,性别为女性这样的组合查询。倒排索引很多地方都有介绍,但是其比关系型
为什么mysql不推荐使用雪花ID作为主键
作者:毛辰飞背景在mysql中设计表的时候,mysql官方推荐不要使用uuid或者不连续不重复的雪花id(long形且唯一),而是推荐连续自增的主键id,官方的推荐是auto_increment,那么为什么不建议采用uuid,使用uuid究