MySql 索引 查询 优化

Posted zhouixi

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了MySql 索引 查询 优化相关的知识,希望对你有一定的参考价值。

官方文档:
  https://dev.mysql.com/doc/refman/5.7/en/explain-output.html#explain_rows

type: 连接类型 system 表只有一行 const 表最多只有一行匹配,通用用于主键或者唯一索引比较时。如将主键置于where列表中,MySQL就能将该查询转换为一个常量 eq_ref 每次与之前的表合并行都只在该表读取一行,这是除了system,const之外最好的一种,特点是使用=,而且索引的所有部分都参与join且索引是主键或非空唯一键的索引 ref 如果每次只匹配少数行,那就是比较好的一种,使用=或
<=>,可以是左覆盖索引或非主键或非唯一键 fulltext 全文搜索 ref_or_null    与ref类似,但包括NULL index_merge 表示出现了索引合并优化(包括交集,并集以及交集之间的并集),但不包括跨表和全文索引。 这个比较复杂,目前的理解是合并单表的范围索引扫描(如果成本估算比普通的range要更优的话) unique_subquery 在in子查询中,就是value in (select...)把形如“select unique_key_column”的子查询替换。PS:所以不一定in子句中使用子查询就是低效的! index_subquery 同上,但把形如”select non_unique_key_column“的子查询替换 range 常数值的范围(索引范围扫描),对索引的扫描开始于某一点,返回匹配值域的行,常见于between、<>等的查询 index a.当查询是索引覆盖的,即所有数据均可从索引树获取的时候(Extra中有UsingIndex); b.以索引顺序从索引中查找数据行的全表扫描(无 UsingIndex); c.如果Extra中Using Index与Using Where同时出现的话,则是利用索引查找键值的意思; d.如单独出现,则是用读索引来代替读行,但不用于查找 all 遍历全表以找到匹配的行 null:MySQL在优化过程中分解语句,执行时甚至不用访问表或索引结果值从好到坏依次是: system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
explain 执行计划分类。
摘自:
https://blog.csdn.net/q936889811/article/details/72576182
抛问题:

 

 

三个表每个表大概数据在5300左右。

做一个统计都要17S。有很大的优化空间。简单的办法就是加索引。具体走单索引还是组合索引。具体看业务情况这里走的是

单索引。

开测:先给三个表加索引。

添加索引:三个表类似 order_number用于on字段 e_id 用于where条件。



先试试JOIN写法


查询时间:0.022S 从17S优化到0.022S.

看一下执行计划:

  这条SQL我没有执行WHERE 条件 。也就是没有使用之前建的e_id_index索引。

   主要看执行计划的 type 对比下 

   还有优化的空间。o表走的index 没有把索引的作用发挥到极致。现在加上where 看一下

  

注意: o表的index从变成了ref: rows 从5411变成了2705

ref:如果每次只匹配少数行,那就是比较好的一种,使用=或<=>,可以是左覆盖索引或非主键或非唯一键
index a.当查询是索引覆盖的,即所有数据均可从索引树获取的时候(Extra中有UsingIndex);
b.以索引顺序从索引中查找数据行的全表扫描(无 UsingIndex);
c.如果Extra中Using Index与Using Where同时出现的话,则是利用索引查找键值的意思;
d.如单独出现,则是用读索引来代替读行,但不用于查找
从返回时间上来,区别是不大的。但从优化的角度上说后者更佳  

再看看IN EXISTS的区别 ,很多人说IN不走索引 走的全表扫描
IN

EXISTS


o表索引都引用的eid_index 没啥子大区别。
主要看o1索引 从un_index变成了eq_ref
对于un_index的说明看官方说明


不做翻译
相比之下,exists比in更能发挥索引的作用并不是in性能就差这里只是简单测试一下。
并不能完全保存exists就能优势于in.需要去更多的业务环境下发现,实践。

再看看LIKE走没走索引。LIKE很多人认为性能差,看计划上区别上大不大。这里只做简单分析不做深入。

全LIKE
左原则


这两个写法都是用到了索引区别不是很大。这边用的单索引。没有用组合索引。


再看看select * 跟单个字段的区别


between ...and .... 等同于 <> != 非等值




再看看隐式转换的区别
隐式转换

正常写法加了单引。

这里直接从ref eq_ref 升级成const const. 当数据量大的时候 ,返回时间是有很大区别的。

所以说平时写SQL一定要注意格式。千万别偷懒

效果是一样的。个人理解除了IO的消耗,没感觉哪里有区别。也不知道为什么很多人都说* 性能差。但又说不出来个所以然。

 

对于SQL优化简单总结一下:

1.避免字段NULL 用not null default \'xxx\'填充。这里NULL值,我并没有去实践小懒一下。个人理解这可能跟索引的本身的数据结构有关系

2.能用等值操作就用等值操作。

3.业务条件允许的情况下能不用LIKE就不用 用第三方的 es solr 搜索引擎代替。

4.避免隐式转换

5.把ON字段关联加上索引

6.尽量用where强制使用索引

7.尽量用EXISTS 代替IN 。相比之下IN可读性高。EXISTS性能略胜IN。并不是说EXISTS绝对比IN好,需要在更多的业务环境实践。自行体会。

8.避免用* 减小IO消耗

9.字段设计 char varchar nvarch text / int bigint tinyint 能小则小。

10.表设计尽量使用物理外键可以用逻辑外键。

11.因为MYSQL没有 with as cte写法这里没有做演示  。在MSSQL ORACLE都是有的。性能相对来说比较好。走内存。

12.充分利用临时表,变量表,

13.UNION ALL UNAION 区别在于一个去重一个不去重。看业务场景。能不用就不用。把每个查询结果做重处理。避免UNION ALL

14.如果表关联过多,可以通过程序去拆分。不要一条SQL写的贼长。并不是SQL写的长就是叼。装逼有罪。

15.SQL很强大,多多练习 。

 

以上是关于MySql 索引 查询 优化的主要内容,如果未能解决你的问题,请参考以下文章

mysql--索引优化

Elasticsearch笔记九之优化

MySql查询性能优化必知必会

如何为MySQL查询优化选择最佳索引

MySQL索引和查询优化

MySQL索引优化与查询优化(重点:索引失效的11种情况)