mysql 联合索引 单列索引_Mysql优化-mysql索引-多个单列索引、联合索引

Mysql优化-mysql索引-多列索引、联合索引

说明

为了提高数据库效率，建索引是家常便饭，而在实际工作中，多条件搜索是我们最常用到的，整理一下多条件搜索时如何选择建立索引。

相关介绍

索引确实可以极大的提高我们的查询效率,但是并不是索引建立的越多就越能提高我们的查询效率。当我们建立多个索引时，一方面会占用我们很多的磁盘空间,另一方面当我们进行多列联合查询时，Mysql会自动帮我们选择索引效率高的那一个，而不是都用上，当然mysql有自己的index_merge原则,但是那也是在个别条件下。所以我们在建立索引时，比起多个单列索引来说，联合索引才是我们日常工作中最优的那个解决方案。

联合索引讲解

介绍

联合索引是将多个列字段联合起来建立索引，它是我们常用的索引建立方式。联合索引是左匹配特性：当建立(a,b,c)这样的联合索引时，b+树是按照从左到右的顺序来建立搜索树的。类似于第一步要先查a列，第二步要查b列，第三步要查c列。当where条件是这样的查询顺序时，索引就会起作用。例:(a=1,b=2,c=4),(a=1，b=2)如果不是按顺序查询，跳跃时查询时，那索引就会失效或者起到很小的作用。例：(a=1,c=3) 这种情况下只有a列索引才发挥作用，c列不可以。(b=2,c=3)这种情况索引就完全没有起作用。 建立(a,b,c)的联合索引 语句 索引是否起作用 分析

where a=1 and b=2 and c=3 是 符合左匹配原则

where a=1 and b=2 是 符合左匹配原则

where a=1 and c=3 a列索引生效,c列不生效 找到a之后,要全部查询b,无法快速查询,索引失效

where a=1 and b>10 and c=3 a列索引生效,b列不生效,c列不生效 当出现范围查询时,索引情况会根据范围大小而定,范围很大时,索引失效

where a=1 or b=10 and c=3 索引失效 当出现or条件时,俩个字段中有一个没有索引的话,引擎会放弃索引而产生全表扫描

where a=3 and b like ‘xxxx%’ and c=7 a列索引生效,b列不生效,c列不生效 当使用like时,索引情况会根据范围大小而定,范围很大时,索引失效

where a=3 and b like ‘xxxx%’ and c=7 a列索引生效,b列不生效,c列不生效 当使用like时,索引情况会根据范围大小而定,范围很大时,索引失效

where a=3 and b like ‘xxxx%’ and c=7 a列索引生效,b列不生效,c列不生效 当使用like时,索引情况会根据范围大小而定,范围很大时,索引失效

测试题 通过上边总结的结论，大家可以自己思考一下这个题，然后后面我会给大家分析一下。 题:假设某个表有一个联合索引(c1,c2,c3,c4)以下哪一个能使用该联合索引的c1,c2,c3部分

A where c1=x and c2=x and c4>x and c3=x

B where c1=x and c2=x and c4=x order by c3

C where c1=x and c4= x group by c3,c2

D where c1=x and c5=x order by c2,c3

E where c1=x and c2=x and c5=? order by c2,c3

测试

总结

多个单列索引

多个单列索引就是在经常做联合查询的几个字段上都加上索引,我们接下来也通过测试看一下他跟联合索引的区别。

1.多个单列索引联合查询时，我们发现三个单列索引只有 djh 有效，其他两个都没有用上。

那么为什么没有用上呢？按照我们的理解，三个字段都加索引了，无论怎么排列组合查询，应该都能利用到这三个索引才对！

其实这里其实涉及到了mysql优化器的优化策略！当多条件联合查询时，优化器会评估用哪个条件的索引效率最高！它会选择最佳的索引去使用，也就是说，此处patient_id 、djh 、yldylb这三个索引列都能用，只不过优化器判断只需要使用djh这一个索引就能完成本次查询，故最终explain展示的key为djh。

2.查询条件用or时

我们在网上可能常常看到有人说or会导致索引失效，其实这并不准确。而且我们首先需要判断用的是哪个数据库哪个版本，什么引擎？

比如我用的是mysql5.7版本，innodb引擎，在这个环境下我们再去讨论索引的具体问题。所谓的索引失效指的是：假如or连接的俩个查询条件字段中有一个没有索引的话,引擎会放弃索引而产生全表扫描。我们从or的基本含义出发应该能理解并认可这种说法，没啥问题。

3.index_merge

当我们使用or进行多列索引时，我们要注意此时的type类型为index_merge。 mysql> explain select * from user where yldylb='aaaa' or djh="1111111";

+----+-------------+-------+-------------+---------------+------+---------+------+------+-------------------------------+

| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |

+----+-------------+-------+-------------+---------------+------+---------+------+------+-------------------------------+

| 1 | SIMPLE | user |# index_merge | b,c | c,b | 93,63 | NULL | 2 | Using union(c,b); Using where |

+----+-------------+-------+-------------+---------------+------+---------+------+------+-------------------------------+

index_merge即为索引合并优化 1、索引合并是把几个索引的范围扫描合并成一个索引。

2、索引合并的时候，会对索引进行并集，交集或者先交集再并集操作，以便合并成一个索引。

3、这些需要合并的索引只能是一个表的。不能对多表进行索引合并。

index_merge应用场景： 1.对OR语句求并集，如查询SELECT * FROM TB1 WHERE c1="xxx" OR c2=""xxx"时，如果c1和c2列上分别有索引，可以按照c1和c2条件进行查询，再将查询结果合并(union)操作，得到最终结果

2.对AND语句求交集，如查询SELECT * FROM TB1 WHERE c1="xxx" AND c2=""xxx"时，如果c1和c2列上分别有索引，可以按照c1和c2条件进行查询，再将查询结果取交集(intersect)操作，得到最终结果

3.对AND和OR组合语句求结果

结论

通俗理解：

利用索引中的附加列，您可以缩小搜索的范围，但使用一个具有两列的索引 不同于使用两个单独的索引。复合索引的结构与电话簿类似，人名由姓和名构成，电话簿首先按姓氏对进行排序，然后按名字对有相同姓氏的人进行排序。如果您知道姓，电话簿将非常有用；如果您知道姓和名，电话簿则更为有用，但如果您只知道名不姓，电话簿将没有用处。

所以说创建复合索引时，应该仔细考虑列的顺序。对索引中的所有列执行搜索或仅对前几列执行搜索时，复合索引非常有用；仅对后面的任意列执行搜索时，复合索引则没有用处。

重点：

多个单列索引在多条件查询时优化器会选择最优索引策略，可能只用一个索引，也可能将多个索引全用上！ 但多个单列索引底层会建立多个B+索引树，比较占用空间，也会浪费一定搜索效率，故如果只有多条件联合查询时最好建联合索引！

最左前缀原则：

顾名思义是最左优先，以最左边的为起点任何连续的索引都能匹配上，

注：如果第一个字段是范围查询需要单独建一个索引

注：在创建联合索引时，要根据业务需求，where子句中使用最频繁的一列放在最左边。这样的话扩展性较好，比如 userid 经常需要作为查询条件，而 mobile 不常常用，则需要把 userid 放在联合索引的第一位置，即最左边

同时存在联合索引和单列索引(字段有重复的)，这个时候查询mysql会怎么用索引呢？

这个涉及到mysql本身的查询优化器策略了，当一个表有多条索引可走时, Mysql 根据查询语句的成本来选择走哪条索引；

有人说where查询是按照从左到右的顺序，所以筛选力度大的条件尽量放前面。网上百度过，很多都是这种说法，但是据我研究，mysql执行优化器会对其进行优化，当不考虑索引时，where条件顺序对效率没有影响，真正有影响的是是否用到了索引！

联合索引本质：

当创建(a,b,c)联合索引时，相当于创建了(a)单列索引，(a,b)联合索引以及(a,b,c)联合索引**

想要索引生效的话,只能使用 a和a,b和a,b,c三种组合；当然，我们上面测试过，a,c组合也可以，但实际上只用到了a的索引，c并没有用到！

注：这个可以结合上边的 通俗理解 来思考！**

其他知识点：

1、需要加索引的字段，要在where条件中

2、数据量少的字段不需要加索引；因为建索引有一定开销，如果数据量小则没必要建索引(速度反而慢)

3、避免在where子句中使用or来连接条件,因为如果俩个字段中有一个没有索引的话,引擎会放弃索引而产生全表扫描

4、联合索引比对每个列分别建索引更有优势，因为索引建立得越多就越占磁盘空间，在更新数据的时候速度会更慢。另外建立多列索引时，顺序也是需要注意的，应该将严格的索引放在前面，这样筛选的力度会更大，效率更高。

最后的说明：

网上关于索引优化等文章太多了，针对各个数据库各个版本各种引擎都可能存在不一样的说法！

我们的SQL引擎自带的优化也越来越强大，说不定你的某个SQL优化认知，其SQL引擎在某次升级中早就自优化了。

所以要么跟进官方文档，要么关注数据库大牛的最新文章，要么在现有数据库环境下自己去亲手测试！

数据库领域的水很深。。大家加油。。共勉 ~

结尾

本文原文链接为https://blog.csdn.net/Abysscarry/article/details/80792876 ,mysql有关优化索引优化的知识点还有还有很多，博主也是在学习的路上，等了解更多之后博主会回来重写这个文章，到时候会给大家更详细的讲解这部分的知识。

腹有诗书气自华，最是书香能致远。

本文由 张六六柒 创作，采用 知识共享署名4.0 国际许可协议进行许可

本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名

最后编辑时间为: Feb 14, 2020 at 03:43 am