MySQL的复合索引总结

目录
  • 1.背景
  • 2.认识复合索引
  • 3.最左匹配原则
  • 4.字段顺序的影响
  • 5.单字段是否可以触发索引?
  • 7.复合索引可以替代单一索引吗?

1.背景

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

2.认识复合索引

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

组合索引有啥优势呢?

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

缺点:

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

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

3.最左匹配原则

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

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

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

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

4.字段顺序的影响

复合索引遵从最左匹配原则,那么在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语句中的字段顺序并不需要与复合索引字段顺序一致,查询优化器会自动调整顺序。

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

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

对于复合索引为(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;

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

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

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

explain select * from t_user where c2 = 4;

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

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

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

单一索引:

(c1),

复合索引:

(c1,c2)。

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

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

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

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

小结:

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

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

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

到此这篇关于MySQL的复合索引总结的文章就介绍到这了,更多相关MySQL复合索引内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • MySQL复合索引的深入探究

    复合索引(又称为联合索引),是在多个列上创建的索引.创建复合索引最重要的是列顺序的选择,这关系到索引能否使用上,或者影响多少个谓词条件能使用上索引.复合索引的使用遵循最左匹配原则,只有索引左边的列匹配到,后面的列才能继续匹配.本文主要探究复合索引的创建顺序与使用情况. (一)复合索引的概念 在单个列上创建的索引我们称为单列索引,在2个以上的列上创建的索引称为复合索引.在单个列上创建索引相对简单,通常只需要考虑列的选择率即可,选择性越好,代表数据越分散,创建出来的索引性能也就更好.通常,某列选择率

  • Mysql limit 优化,百万至千万级快速分页 复合索引的引用并应用于轻量级框架

    MySql 这个数据库绝对是适合dba级的高手去玩的,一般做一点1万篇新闻的小型系统怎么写都可以,用xx框架可以实现快速开发.可是数据量到了10万,百万至千万,他的性能还能那么高吗?一点小小的失误,可能造成整个系统的改写,甚至更本系统无法正常运行!好了,不那么多废话了.用事实说话,看例子: 数据表 collect ( id, title ,info ,vtype) 就这4个字段,其中 title 用定长,info 用text, id 是逐渐,vtype是tinyint,vtype是索引.这是一个

  • mysql的联合索引(复合索引)的实现

    联合索引 本文中联合索引的定义为(MySQL): ALTER TABLE `table_name` ADD INDEX (`col1`,`col2`,`col3`); 联合索引的优点 若多个一条SQL,需要多个用到两个条件 SELECT * FROM `user_info` WHERE username='XX',password='XXXXXX'; 当索引在检索 password字段的时候,数据量大大缩小,索引的命中率减小,增大了索引的效率. 符合索引的索引体积比单独索引的体积要小,而且只是一

  • 当Mysql行锁遇到复合主键与多列索引详解

    背景 今天在配合其他项目组做系统压测,过程中出现了偶发的死锁问题.分析代码后发现有复合主键的update情况,更新复合主键表时只使用了一个字段更新,同时在事务内又有对该表的insert操作,结果出现了偶发的死锁问题. 比如表t_lock_test中有两个主键都为primary key(a,b) ,但是更新时却通过update t_lock_test .. where a = ? ,然后该事务内又有insert into t_lock_test values(...) InnoDB中的锁算法是Ne

  • MySQL的复合索引总结

    目录 1.背景 2.认识复合索引 3.最左匹配原则 4.字段顺序的影响 5.单字段是否可以触发索引? 7.复合索引可以替代单一索引吗? 1.背景 最近频繁出现慢SQL导致系统性能问题,于是决定针对索引进行一些优化.一些表结构本身已经有了不少索引,如果再继续添加索引,势必会影响到插入数据的性能.那么,是否可以使用组合索引来达到目的呢?这篇文章咱们来一探究竟. 2.认识复合索引 如果where条件中使用到多个字段,并且需要对多个字段建立索引,此时就可以考虑采用复合索引(组合索引).比如查询地址时需要

  • Mysql的复合索引如何生效

    目录 背景 认识复合索引 最左匹配原则 字段顺序的影响 复合索引可以替代单一索引吗? 小结 背景 最近频繁出现慢SQL导致系统性能问题,于是决定针对索引进行一些优化.一些表结构本身已经有了不少索引,如果再继续添加索引,势必会影响到插入数据的性能.那么,是否可以使用组合索引来达到目的呢?这篇文章咱们来一探究竟. 认识复合索引 如果where条件中使用到多个字段,并且需要对多个字段建立索引,此时就可以考虑采用复合索引(组合索引).比如查询地址时需要输入省.市,那么在省.市上建立索引,当数据量大时会明

  • 浅谈MySQL和Lucene索引的对比分析

    MySQL和Lucene都可以对数据构建索引并通过索引查询数据,一个是关系型数据库,一个是构建搜索引擎(Solr.ElasticSearch)的核心类库.两者的索引(index)有什么区别呢?以前写过一篇<Solr与MySQL查询性能对比>,只是简单的对比了下查询性能,对于内部原理却没有解释,本文简单分析下两者的索引区别. MySQL索引实现 在MySQL中,索引属于存储引擎级别的概念,不同存储引擎对索引的实现方式是不同的,本文主要讨论MyISAM和InnoDB两个存储引擎的索引实现方式. M

  • MySQL中对于索引的基本增删查改操作总结

    创建索引 MySQL创建索引的语法如下: CREATE [UNIQUE|FULLTEXT|SPATIAL] INDEX index_name [USING index_type] ON table_name (index_col_name,...) 其中对应的语法变量信息如下: [UNIQUE|FULLTEXT|SPATIAL] 中括号中的这三个关键字表示创建的索引类型,它们分别表示唯一索引.全文索引.空间索引三种不同的索引类型.如果我们不指定任何关键字,则默认为普通索引. index_name

  • Oracle复合索引与空值的索引使用问题小结

    昨天在QQ群里讨论一个SQL优化的问题,语句大致如下: select A,min(B) from table group by A;--A,B都没有not null约束,A列无空值,B列有空值.--存在复合索引IX_TEST(A,B) 于是手动测试,环境采用Oracle自带的scott用户下的emp表. 1.首先查看如下语句的执行计划(此时表只有主键索引): 2.添加IX_TEST(deptno,comm)后查看执行计划: 发现依然是全表扫描. 3.为deptno列添加非空约束后再次查看执行计划

  • 深入理解MongoDB的复合索引

    为什么需要索引? 当你抱怨MongoDB集合查询效率低的时候,可能你就需要考虑使用索引了,为了方便后续介绍,先科普下MongoDB里的索引机制(同样适用于其他的数据库比如mysql). mongo-9552:PRIMARY> db.person.find() { "_id" : ObjectId("571b5da31b0d530a03b3ce82"), "name" : "jack", "age" :

  • MySQL如何优化索引

    1.  MySQL如何使用索引 索引用于快速查找具有特定列值的行.如果没有索引,MySQL必须从第一行开始,然后遍历整个表以找到相关的行.表越大,花费越多.如果表中有相关列的索引,MySQL可以快速确定要在数据文件中间查找的位置,而不必查看所有数据.这比顺序读取每一行要快得多. 大多数MySQL索引(PRIMARY KEY,UNIQUE,INDEX和FULLTEXT)存储在B树(B-tree)中.例外情况:空间数据类型的索引使用R树: MEMORY表还支持哈希索引. InnoDB对FULLTEX

随机推荐