MySQL执行计划extra中的using index 和 using where using index 的区别

原文:MySQL执行计划extra中的using index 和 using where using index 的区别

 

本文出处:http://www.cnblogs.com/wy123/p/7366486.html 
(保留出处并非什么原创作品权利,本人拙作还远远达不到,仅仅是为了链接到原文,因为后续对可能存在的一些错误进行修正或补充,无他)

 

mysql执行计划中的extra列中表明了执行计划的每一步中的实现细节,其中包含了与索引相关的一些细节信息
其中跟索引有关的using index 在不同的情况下会出现Using index, Using where Using index ,Using index condition等
那么Using index 和 Using where;Using index 有什么区别?网上搜了一大把文章,说实在话也没怎么弄懂,于是就自己动手试试。

本文仅从最简单的单表去测试using index 和 using where using index以及简单测试using index condition的情况的出现时机 。
执行计划的生成与表结构,表数据量,索引结构,统计信息等等上下文等多种环境有关,无法一概而论,复杂情况另论。

 

测试环境搭建

  测试表以及测试数据搭建,类似于订单表和订单明细表,暂时先用订单表做测试

  测试表结构

create table test_order
(
    id int auto_increment primary key,
    user_id int,
    order_id int,
    order_status tinyint,
    create_date datetime
);

create table test_orderdetail
(
    id int auto_increment primary key,
    order_id int,
    product_name varchar(100),
    cnt int,
    create_date datetime
);

create index idx_userid_order_id_createdate on test_order(user_id,order_id,create_date);

create index idx_orderid_productname on test_orderdetail(order_id,product_name);

测试数据(50W)

CREATE DEFINER=`root`@`%` PROCEDURE `test_insertdata`(IN `loopcount` INT)
    LANGUAGE SQL
    NOT DETERMINISTIC
    CONTAINS SQL
    SQL SECURITY DEFINER
    COMMENT ''
BEGIN
    declare v_uuid  varchar(50);
    while loopcount>0 do
        set v_uuid = uuid();
        insert into test_order (user_id,order_id,order_status,create_date) values (rand()*1000,id,rand()*10,DATE_ADD(NOW(), INTERVAL - RAND()*20000 HOUR));
        insert into test_orderdetail(order_id,product_name,cnt,create_date) values (rand()*100000,v_uuid,rand()*10,DATE_ADD(NOW(), INTERVAL - RAND()*20000 HOUR));
        set loopcount = loopcount -1;
    end while;
END

 

Using index VS Using where Using index

  首先,在"订单表"上,这里是一个多列复合索引
  create index idx_userid_order_id_createdate on test_order(user_id,order_id,create_date);

 

Using index 

1,查询的列被索引覆盖,并且where筛选条件是索引的是前导列,Extra中为Using index

 

Using where Using index

  1,查询的列被索引覆盖,并且where筛选条件是索引列之一但是不是索引的不是前导列,Extra中为Using where; Using index,
    意味着无法直接通过索引查找来查询到符合条件的数据

2,查询的列被索引覆盖,并且where筛选条件是索引列前导列的一个范围,同样意味着无法直接通过索引查找查询到符合条件的数据

   

NULL(既没有Using index,也没有Using where Using index,也没有using where

  1,查询的列未被索引覆盖,并且where筛选条件是索引的前导列,
       意味着用到了索引,但是部分字段未被索引覆盖,必须通过“回表”来实现,不是纯粹地用到了索引,也不是完全没用到索引,Extra中为NULL(没有信息)

 

Using where

  1,查询的列未被索引覆盖,where筛选条件非索引的前导列,Extra中为Using where

  2,查询的列未被索引覆盖,where筛选条件非索引列,Extra中为Using where

   

  using where 意味着通过索引或者表扫描的方式进程where条件的过滤,
  反过来说,也就是没有可用的索引查找,当然这里也要考虑索引扫描+回表与表扫描的代价。
  这里的type都是all,说明MySQL认为全表扫描是一种比较低的代价。

 Using index condition

  1,查询的列不全在索引中,where条件中是一个前导列的范围

  

  2,查询列不完全被索引覆盖,查询条件完全可以使用到索引(进行索引查找)

  

  参考:MySQL · 特性分析 · Index Condition Pushdown (ICP)
  using index conditoin 意味着查询列的某一部分无法直接使用索引
  上述case1中,
  如果禁用ICP(set optimizer_switch='index_condition_pushdown=off'),
  执行计划是using where,意味着全表扫描,如果启用ICP,执行计划为using index Condition,意味着在筛选的过程中实现过滤
  上述case1中
  第二个查询条件无法直接使用索引,隐含了一个查找+筛选的过程。
  两个case的共同点就是无法直接使用索引。

 

结论:
  1,Extra中的为Using index的情况
    where筛选列是索引的前导列 &&查询列被索引覆盖 && where筛选条件是一个基于索引前导列的查询,意味着通过索引超找就能直接找到符合条件的数据,并且无须回表

  2,Extra中的为空的情况
    查询列存在未被索引覆盖&&where筛选列是索引的前导列,意味着通过索引超找并且通过“回表”来找到未被索引覆盖的字段,

3,Extra中的为Using where Using index:
  出现Using where Using index意味着是通过索引扫描(或者表扫描)来实现sql语句执行的,即便是索引前导列的索引范围查找也有一点范围扫描的动作,不管是前非索引前导列引起的,还是非索引列查询引起的。

 

尚未解决的问题:

     查询1

 

查询2

    

    查询3(逻辑上等价于查询1+查询2),执行计划发生了很大的变化。

 

总结:

  MySQL执行计划中的Extra中信息非常多,不仅仅包括Using index,Using where Using index,Using index condition,Using where,尤其是在多表连接的时候,这一点在相对MSSQL来说,不够直观或者结构化。
  MSSQL中是通过区分索引查找(index seek),索引扫描(index scan),表扫描(table scan)来实现具体的查询的,这图形化的执行计划在不同的场景下是非常直观的,要想完全弄懂MySQL的这个执行计划,可能要更多地在实践中摸索。

 

时间: 2024-11-03 16:26:56

MySQL执行计划extra中的using index 和 using where using index 的区别的相关文章

mysql执行计划介绍_Mysql

烂sql不仅直接影响sql的响应时间,更影响db的性能,导致其它正常的sql响应时间变长.如何写好sql,学会看执行计划至关重要.下面我简单讲讲mysql的执行计划,只列出了一些常见的情况,希望对大家有所帮助. 测试表结构: 复制代码 代码如下: CREATE TABLE `t1` (  `c1` int(11) NOT NULL DEFAULT '0',  `c2` varchar(128) DEFAULT NULL,  `c3` varchar(64) DEFAULT NULL,  `c4`

MySQL执行计划explain的key_len解析

当用Explain查看SQL的执行计划时,里面有列显示了 key_len 的值,根据这个值可以判断索引的长度,在组合索引里面可以更清楚的了解到了哪部分字段使用到了索引.下面演示中,表结构的合理性这边暂且不说,只是证明一下索引长度的计算方法.目前大部分博文是字符类型的索引长度计算方法,下面列举几个类型的索引长度计算方法: 1.整数类型 (dg1)root@127.0.0.1 [mytest]> desc table_key; +---------+-------------+------+----

MySQL执行计划里面的key_len

  以前看MySQL的执行计划,感觉内容有些简陋,平时分析主要就是看是否全表扫描,索引使用是否合理等.基本上也能分析出很多问题来,但是显然有时候会有些疑惑,那就是对于复合索引,多列值的情况下,到底启用了那些索引列,这个时候索引的使用情况就很值得琢磨琢磨了,我们得根据执行计划里面的key_len做一个重要的参考.    我们做一个简单的测试来说明.    CREATE TABLE `department` ( `DepartmentID` int(11) DEFAULT NULL, `Depart

mysql 执行计划优化

一条简单的SQL 语句竟花了15.87 sec, 写道 mysql> SELECT x.loc AS loc, x.lastmod AS lastmod, x.changefreq AS changefreq, x.changecount AS changecount, x.priority AS priority, x.language AS language, x.ac cess AS access, x.status AS status FROM xmlsitemap x WHERE (x

MySQL学习系列2--MySQL执行计划分析EXPLAIN

原文:MySQL学习系列2--MySQL执行计划分析EXPLAIN 1.Explain语法 EXPLAIN SELECT -- 变体:   EXPLAIN EXTENDED SELECT -- 将执行计划"反编译"成SELECT语句,运行SHOW WARNINGS 可得到被MySQL优化器优化后的查询语句   2.执行计划分析和实例 创建员工表Employee create table Employee ( ID int auto_increment, Ename varchar(32

MySQL 索引管理与执行计划

1.1 索引的介绍 索引是对数据库表中一列或多列的值进行排序的一种结构,使用索引可快速访问数据库表中的特定信息.如果想按特定职员的姓来查找他或她,则与在表中搜索所有的行相比,索引有助于更快地获取信息. 索引的一个主要目的就是加快检索表中数据的方法,亦即能协助信息搜索者尽快的找到符合限制条件的记录ID的辅助数据结构. 1.1.1 唯一索引 唯一索引是不允许其中任何两行具有相同索引值的索引.当现有数据中存在重复的键值时,大多数数据库不允许将新创建的唯一索引与表一起保存.数据库还可能防止添加将在表中创

谈一谈SQL Server中的执行计划缓存(下)

原文:谈一谈SQL Server中的执行计划缓存(下) 简介     在上篇文章中我们谈到了查询优化器和执行计划缓存的关系,以及其二者之间的冲突.本篇文章中,我们会主要阐述执行计划缓存常见的问题以及一些解决办法.   将执行缓存考虑在内时的流程     上篇文章中提到了查询优化器解析语句的过程,当将计划缓存考虑在内时,首先需要查看计划缓存中是否已经有语句的缓存,如果没有,才会执行编译过程,如果存在则直接利用编译好的执行计划.因此,完整的过程如图1所示. 图1.将计划缓存考虑在内的过程      

谈一谈SQL Server中的执行计划缓存(上)

原文:谈一谈SQL Server中的执行计划缓存(上) 简介     我们平时所写的SQL语句本质只是获取数据的逻辑,而不是获取数据的物理路径.当我们写的SQL语句传到SQL Server的时候,查询分析器会将语句依次进行解析(Parse).绑定(Bind).查询优化(Optimization,有时候也被称为简化).执行(Execution).除去执行步骤外,前三个步骤之后就生成了执行计划,也就是SQL Server按照该计划获取物理数据方式,最后执行步骤按照执行计划执行查询从而获得结果.但查询

浅析SQL Server中的执行计划缓存(下)_MsSql

在上篇文章给大家介绍了SQL Server中的执行计划缓存(上),本文继续给大家介绍sqlserver执行计划缓存相关知识,小伙伴们一起学习吧. 简介 在上篇文章中我们谈到了查询优化器和执行计划缓存的关系,以及其二者之间的冲突.本篇文章中,我们会主要阐述执行计划缓存常见的问题以及一些解决办法. 将执行缓存考虑在内时的流程 上篇文章中提到了查询优化器解析语句的过程,当将计划缓存考虑在内时,首先需要查看计划缓存中是否已经有语句的缓存,如果没有,才会执行编译过程,如果存在则直接利用编译好的执行计划.因