首页 / MYSQL / mysql执行计划初步解读1
mysql执行计划初步解读1
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了mysql执行计划初步解读1,小编现在分享给大家,供广大互联网技能从业者学习和参考。文章包含7432字,纯文字阅读大概需要11分钟。
内容图文
![mysql执行计划初步解读1](/upload/InfoBanner/zyjiaocheng/916/ebf7746ed9bb41179f800a3ffb504b2c.jpg)
Mysql的执行计划算是一个平时接触比较少的部分。惭愧,平时的sql优化都是直接看sql,然后一列一列条件的debug,并没有一个科学的统计方法。抽空看了一些关于执行计划的内容,感觉收获颇丰。
执行计划格式
首先我们先简单看一下执行计划是什么东西。
关联一下简单的订单和订单商品join得到的结果:
ok,执行计划表总共有12列,每一列的含义,我们一一道来。
1.id,表示每一个子句的操作顺序,id越大,优先级越高。
对于每一个平级查询,id是一致的,表示操作的优先级查询;
对于有子查询的sql,可以看到子查询的优先级是比外层查询要高的。也比较符合我们的主观意识,先查子表,才能查主表。
但是注意,并不是所有带有子查询语句的sql一定会是子查询,例如如下语句:
关于sql优化器的优化规则,我不再多讲解,一是本章的主要内容不是讲这方面的内容,二是我自己领悟的也不够。
2.select_type,查询类型
1)SIMPLE,简单查询,表示不包含子查询或者UNION子句
2)PRIMARY,表示查询语句包含子查询或者UNION子句,PRIMARY表示外层的语句
3)SUBQUEY,子查询语句
4)UNION union 位于union中第二个及其以后的子查询被标记为union
5)DERIVED 在from列表中包含的子查询被标记为derived(衍生)
6)DEPENDENT UNION UNION中的第二个或后面的SELECT语句,取决于外面的查询
7)UNION RESULT UNION的结果
6和7我本人并不是十分理解,不再加以展示
3.table,需要查询表,这个有可能是数据库表或临时表
4.partitions,匹配到的分区,出现于分表查询中的情况
5.type,访问类型,这个指标是sql查询优化中很重要的一个指标
常会出现的几个枚举值如下:
system:表中只有一行记录,相当于系统表
const:通过索引一次命中,匹配一行数据
eq_ref:唯一性索引扫描,对于每个索引键,表中只有一条记录与之匹配,常用语主键或唯一索引扫描
ref:非唯一性索引扫描,返回匹配某个单独值的所有行,用于=、<或>操作符带索引的列
range:只检索给定范围的行,使用一个索引来选择行,一般用于between、<、>;
index:只遍历索引树;
all:全表扫描;
从上到下的执行效率是依次降低的,前5种情况都是理想的索引的情况。通常优化至少到range级别,最好能优化到ref。
列举一些例子:
system是const的一个特例,表中只有一行数据时使用
我在订单编号上建立了唯一索引,通过下图(呃呃,不知道为啥传不了图片了,直接粘结果吧)可以看出,当主键或者唯一索引位于where条件时,那么执行的类型为const
mysql> explain select * from `order` where title = 'C1086407110000019';
+----+-------------+-------+------------+-------+---------------+--------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+-------+---------------+--------+---------+-------+------+----------+-------+
| 1 | SIMPLE | order | NULL | const | 订单 | 订单 | 1023 | const | 1 | 100.00 | NULL |
+----+-------------+-------+------------+-------+---------------+--------+---------+-------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)
mysql> explain select * from `order` where id = 1;
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
| 1 | SIMPLE | order | NULL | const | PRIMARY | PRIMARY | 8 | const | 1 | 100.00 | NULL |
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)
而eq_ref的区别为,eq_ref使用在关联查询上,如下:
mysql> explain select * from `order` left join order_item on `order`.id = order_item.order_id where `order`.id = 1;
+----+-------------+------------+------------+-------+---------------+-----------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+------------+------------+-------+---------------+-----------+---------+-------+------+----------+-------+
| 1 | SIMPLE | order | NULL | const | PRIMARY | PRIMARY | 8 | const | 1 | 100.00 | NULL |
| 1 | SIMPLE | order_item | NULL | ref | 订单号 | 订单号 | 8 | const | 2 | 100.00 | NULL |
+----+-------------+------------+------------+-------+---------------+-----------+---------+-------+------+----------+-------+
2 rows in set, 1 warning (0.00 sec)
对于非唯一性索引,比如我们的订单中的用户id,当我们查询时,有可能会使用ref或者range结果如下:
mysql> explain select * from `order` where customer_id = 55029;
+----+-------------+-------+------------+------+---------------+-------------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+-------------+---------+-------+------+----------+-------+
| 1 | SIMPLE | order | NULL | ref | customer_id | customer_id | 8 | const | 10 | 100.00 | NULL |
+----+-------------+-------+------------+------+---------------+-------------+---------+-------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)
mysql> explain select * from `order` where customer_id > 55029 and customer_id < 55129;
+----+-------------+-------+------------+-------+---------------+-------------+---------+------+------+----------+-----------------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+-------+---------------+-------------+---------+------+------+----------+-----------------------+
| 1 | SIMPLE | order | NULL | range | customer_id | customer_id | 8 | NULL | 1 | 100.00 | Using index condition |
+----+-------------+-------+------------+-------+---------------+-------------+---------+------+------+----------+-----------------------+
1 row in set, 1 warning (0.00 sec)
当然如果没有索引的字段,那么执行方式只能是ALL了。
但是值得注意的是,并不是有了索引就一定不会走索引的。如果字段的差异性太小,例如性别字段,即使建了索引,那么也不会走索引的。这里我举一个例子,我拿来做测试的所有订单表中只有一个卖家,这个字段上是有索引的,但是我们来查询一下:
mysql> explain select * from `order` where seller_id = 19;
+----+-------------+-------+------------+------+------------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+------+------------------+------+---------+------+------+----------+-------------+
| 1 | SIMPLE | order | NULL | ALL | 商家,seller_id | NULL | NULL | NULL | 2197 | 100.00 | Using where |
+----+-------------+-------+------------+------+------------------+------+---------+------+------+----------+-------------+
1 row in set, 1 warning (0.00 sec)
发现实际上innodb并没有选择走索引,因为在这种情况下,走索引比不走索引的开销还要大。关于开销,Innodb是基于RBO进行判断的(更古老的判断方式是CBO,这些内容具体已经记得不是很清楚了,想要了解的需要再查找一些相关资料)。
上述几个值并不是全部的枚举值,例如还有fulltext、 index_merge、 unique_subquery等等,不过出现的频次没有什么上述的几个枚举值高而已。
system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
内容总结
以上是互联网集市为您收集整理的mysql执行计划初步解读1全部内容,希望文章能够帮你解决mysql执行计划初步解读1所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错,欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 gblab@vip.qq.com 举报,一经查实,本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。