MYSQL中的type:index 和 Extra:Using index

本文涉及的产品
RDS DuckDB + QuickBI 企业套餐,8核32GB + QuickBI 专业版
RDS Agent(兼容OpenClaw),2核4GB
RDS AI 助手,专业版
简介: 原创水平有限,如有错误请指出 考虑下面执行计划中的TYPE和Extra +----+-------------+--------+------------+-------+---------------+------+---------+------+------...
原创水平有限,如有错误请指出


考虑下面执行计划中的TYPE和Extra

+----+-------------+--------+------------+-------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table  | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+--------+------------+-------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | testud | NULL       | index | NULL          | id2  | 10      | NULL |    3 |   100.00 | Using index |
+----+-------------+--------+------------+-------+---------------+------+---------+------+------+----------+-------------+

type:index 不使用索引B+树结构,只使用索引叶子结点链表结构进行扫描,我们知道在索引的叶子结点有一个叶子结点之间的双向指针,
           并且叶子结点的数据是排序好的。他和ALL的方式类似,访问效率并不高,其主要的应用场景为用于避免order by使用using filesort
           也就是避免排序。他是一种访问数据的方式,和const、ref、eq_ref等一样
Extra:Using index  当二级索引包含了所有的查询需要的所有字段的时候,select查询只需要通过索引及可以
                   获得全部的数据,那么就不需要回表了。注意这里全部数据是条件谓词和查询字段的全部
                   总和比如
                   select id1 from test where id2=1;
                   这个索引必须包含id1和id2,这里有种特殊的情况叫做Index Extensions在后面说明
                   它可以考虑B+树结构如使用type:ref也可以不考虑使用type:index
                   一般来说索引的大小要远远小于表的大小,不管从回表还是读取物理文件的大小来说,使用
                   Using index 都可以提高查询性能。也叫索引覆盖扫描

这两个地方是让人经常容易混淆的,并且它们并不是总是一起出现(虽然可能性不小),实际上他们没有必然的联系
下面是我的测试表结构
mysql> show create table testud;
+--------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Table  | Create Table                                                                                                                                                                                                                        |
+--------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| testud | CREATE TABLE `testud` (
  `id1` int(11) NOT NULL,
  `id2` int(11) DEFAULT NULL,
  `id3` int(11) DEFAULT NULL,
  `id4` int(11) DEFAULT NULL,
  PRIMARY KEY (`id1`),
  KEY `id2` (`id2`,`id3`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 |
+--------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.05 sec)

1、可以单独的出现type:index
mysql> explain select * from testud force index(id2) order by id2;
+----+-------------+--------+------------+-------+---------------+------+---------+------+------+----------+-------+
| id | select_type | table  | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra |
+----+-------------+--------+------------+-------+---------------+------+---------+------+------+----------+-------+
|  1 | SIMPLE      | testud | NULL       | index | NULL          | id2  | 10      | NULL |    3 |   100.00 | NULL  |
+----+-------------+--------+------------+-------+---------------+------+---------+------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)

这里只是代表type=index避免的排序,但是需要从头到尾使用双向链表来访问整个叶子结点
2、可以单独出现Extra:Using index
mysql> explain select id2 from testud where id2=1;
+----+-------------+--------+------------+------+---------------+------+---------+-------+------+----------+-------------+
| id | select_type | table  | partitions | type | possible_keys | key  | key_len | ref   | rows | filtered | Extra       |
+----+-------------+--------+------------+------+---------------+------+---------+-------+------+----------+-------------+
|  1 | SIMPLE      | testud | NULL       | ref  | id2           | id2  | 5       | const |    1 |   100.00 | Using index |
+----+-------------+--------+------------+------+---------------+------+---------+-------+------+----------+-------------+
1 row in set, 1 warning (0.00 sec)
这里type为ref,代表通过一个非唯一的索引进行了单个值的扫描 id2=1,也就是这里的(id2,id3)是非唯一索引,而1是单个值,他考虑了索引
的B+树的结构也就是不仅仅考虑了叶子结点,需要从根结点到分支节点(如果有),再到叶子结点来完成id2=1这种条件的过滤
而因为id2包含在索引(id2,id3)中当然也就使用Using index 就可以了。
从上面两种情况来看type:index和Extra:Using index并没有必然的联系。他们各自代表值的意思

3、共同出现这个就很简单了。
mysql> explain select id2 from testud;
+----+-------------+--------+------------+-------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table  | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+--------+------------+-------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | testud | NULL       | index | NULL          | id2  | 10      | NULL |    3 |   100.00 | Using index |
+----+-------------+--------+------------+-------+---------------+------+---------+------+------+----------+-------------+
1 row in set, 1 warning (0.01 sec)


需要从头到尾使用双向链表来访问整个叶子结点,而索引id2包含了全部的需要的数据。


这里还需要提高Using index的一种特殊场景,也是很多人问过的。官方文档叫做
9.2.1.7 Use of Index Extensions
简单来说比如上面的KEY `id2` (`id2`,`id3`),我们知道叶子结点除了索引自己的数据实际上还有主键的数据在末尾,这个我在前面
已经做过验证,参考:
http://blog.itpub.net/7728585/viewspace-2128817/
这个时候实际上索引id2 包含了 id2 id3 id1 这样排列的数据如果id2相等按照id3排序如果id3相等按照id1排序的这样一种结构,那么
我们的using index就扩大了范围比如下的语句:
mysql> explain select id1,id2,id3 from testud where id2=1;
+----+-------------+--------+------------+------+---------------+------+---------+-------+------+----------+-------------+
| id | select_type | table  | partitions | type | possible_keys | key  | key_len | ref   | rows | filtered | Extra       |
+----+-------------+--------+------------+------+---------------+------+---------+-------+------+----------+-------------+
|  1 | SIMPLE      | testud | NULL       | ref  | id2           | id2  | 5       | const |    1 |   100.00 | Using index |
+----+-------------+--------+------------+------+---------------+------+---------+-------+------+----------+-------------+
1 row in set, 1 warning (0.01 sec)


我们可以看到Using index是生效的。具体可以参考官方文档

最后我们来简单说明一下ORACLE中的索引覆盖扫描
ORACLE中分为2种
index fast full scan:主要按照磁盘物理顺序进行扫描,我们知道链表之所以叫做链表是因为它有指向前或者后的指针比如C语言中经常用
                     *next *pr 来表示前后,既然是指向关系在物理上不一定是有序的。但是这种方式更快,可以使用物理上的多块读取
                     但是其返回数据并不有序,仔细考虑实际上MYSQL中没有这种方式
index full scan:这种访问返回就是有序的,他有点像MYSQL中的index+Using index 方式进行扫描,同样他也是为了避免排序而大量使用
                 的。


作者微信:

               






相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。   相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情: https://www.aliyun.com/product/rds/mysql 
相关文章
|
SQL 关系型数据库 MySQL
MySQL 8.0报错--1118-Row size too large. The maximum row size for the used table type, not counting BLOBs,is 8126,
MySQL 8.0报错--1118-Row size too large. The maximum row size for the used table type, not counting BLOBs,is 8126,
2342 56
MySQL 8.0报错--1118-Row size too large. The maximum row size for the used table type, not counting BLOBs,is 8126,
|
存储 关系型数据库 MySQL
MySQL中为什么要使用索引合并(Index Merge)?
通过这些内容的详细介绍和实际案例分析,希望能帮助您深入理解索引合并及其在MySQL中的
872 10
|
关系型数据库 MySQL 测试技术
MySQL 报错 ERROR 1709: Index column size too large
MySQL 报错 ERROR 1709: Index column size too large
859 4
|
缓存 关系型数据库 MySQL
MySQL数据库——InnoDB引擎-架构-内存结构(Buffer Pool、Change Buffer、Adaptive Hash Index、Log Buffer)
MySQL数据库——InnoDB引擎-架构-内存结构(Buffer Pool、Change Buffer、Adaptive Hash Index、Log Buffer)
395 3
|
存储 关系型数据库 MySQL
MySQL的优化利器⭐️Multi Range Read与Covering Index是如何优化回表的?
本文以小白的视角使用通俗易懂的流程图深入浅出分析Multi Range Read与Covering Index是如何优化回表
|
SQL 关系型数据库 MySQL
mysql查询语句的访问方法const、ref、ref_or_null、range、index、all
mysql查询语句的访问方法const、ref、ref_or_null、range、index、all
|
关系型数据库 MySQL 索引
mysql中force index强制索引
mysql中force index强制索引
665 0
|
关系型数据库 MySQL
mysql 5.5.62版本建表语句报错: Index column size too large. The maximum column size is 767 bytes
mysql 5.5.62版本建表语句报错: Index column size too large. The maximum column size is 767 bytes
840 0
|
SQL 存储 关系型数据库
MySQL - order by 出现 using filesort根因分析及优化
MySQL - order by 出现 using filesort根因分析及优化
611 0
|
关系型数据库 MySQL
MySQL【问题 02】报错 1709 - Index column size too large. The maximum column size is 767 bytes. 可能是最简单的方法
MySQL【问题 02】报错 1709 - Index column size too large. The maximum column size is 767 bytes. 可能是最简单的方法
609 0

推荐镜像

更多