MySQL的loose index scan

众所周知,InnoDB采用IOT(index organization table)即所谓的索引组织表,而叶子节点也就存放了所有的数据,这就意味着,数据总是按照某种顺序存储的。所以问题来了,如果是这样一个语句,执行起来应该是怎么样的呢?语句如下:

select count(distinct a) from table1;

列a上有一个索引,那么按照简单的想法来讲,如何扫描呢?很简单,一条一条的扫描,这样一来,其实做了一次索引全扫描,效率很差。这种扫描方式会扫描到很多很多的重复的索引,这样说的话优化的办法也是很容易想到的:跳过重复的索引就可以了。于是网上能搜到这样的一个优化的办法:

select count(*) from (select distinct a from table1) t;

从已经搜索到的资料看,这样的执行计划中的extra就从using index变成了using index for group-by。

但是,但是,但是,好在我们现在已经没有使用5.1的版本了,大家基本上都是5.5以上了,这些现代版本,已经实现了loose index scan:

很好很好,就不需要再用这种奇技淫巧去优化SQL了。

文档里关于group by这里写的有点意思,说是最大众化的办法就是进行全表扫描并且创建一个临时表,这样执行计划就会难看的要命了,肯定有ALL和using temporary table了。

深刻的感觉这一篇写起来有好多写的,周末再更吧,我要早早睡觉去。

时间: 2025-01-06 00:06:45

MySQL的loose index scan的相关文章

index seek和index scan 提高sql 效率

index seek和index scan 提高sql 效率解释解释index seek和index scan:索引是一颗B树,index seek是查找从B树的根节点开始,一级一级找到目标行.index scan则是从左到右,把整个B树遍历一遍.假设唯一的目标行位于索引树最右的叶节点上(假设是非聚集索引,树深度2,叶节点占用k页物理存储).index seek引起的IO是4,而index scan引起的IO是K,性能差别巨大.关于索引,可以仔细读读联机文档关于物理数据库体系结构部分     查

Index Seek和Index Scan的区别

Index Seek是Sql Server执行查询语句时利用建立的索引进行查找,索引是B树结构,Sql Server先查找索引树的根节点,一级一级向下查找,在查找到相应叶子节点后,取出叶子节点的数据.对于聚集索引,叶子节点是整个表的数据,能够获取到所有列的数据,而对于非聚集索引,叶子节点存储的是索引列的数据,如果索引有包含列,那么叶子节点中存储有包含列的数据,获取的数据是索引列和包含列,如果还需要其他列的数据,那么必须进行key lookup,根据索引叶子节点包含的“行地址”信息到源表中去获取数

浅析MySQL中的Index Condition Pushdown (ICP 索引条件下推)和Multi-Range Read(MRR 索引多范围查找)查询优化

本文出处:http://www.cnblogs.com/wy123/p/7374078.html(保留出处并非什么原创作品权利,本人拙作还远远达不到,仅仅是为了链接到原文,因为后续对可能存在的一些错误进行修正或补充,无他) ICP优化原理 Index Condition Pushdown (ICP),也称为索引条件下推,体现在执行计划的上是会出现Using index condition(Extra列,当然Extra列的信息太多了,只能做简单分析)ICP原理通俗讲就是,查询过程中,直接在查询引擎

Clustered Index Scan 与 Clustered Index Seek

Clustered Index Scan 与 Clustered Index Seek 在利用 SQL Server 查询分析器的执行计划中,会有许多扫描方式,其中就有 Clustered Index Scan 与 Clustered Index Seek,这二者有什么区别呢? Clustered Index,为聚集索引,表示它们使用的都是聚集索引扫描. Scan 表示它扫描一个范围或者是全部内容,Seek 表示扫描特定范围内的行.也就是说 Scan 并不知道要目标行是哪些,而 Seek 扫描表

数据库的Index Scan V.S. Rscan

一直在做performance,但直到今天才完成了这个第一天应该完成的图,到底Index scan和Rscan的分界点在哪里?   如下图所示,很简单的一个查询,只是查询int,分别强制走索引和表扫描,可以看到,大约在4096条记录的时候Index Scan和Rscan可以打平,之后Index scan会永远比Table scan跑的快.   比较奇怪的是128和256的时候,Index Scan会比Table Scan好一些,但原因未知.在128的时候Rscan的CPU time也比Index

转:Sql Server中的表访问方式Table Scan, Index Scan, Index Seek

0.参考文献 Table Scan, Index Scan, Index Seek SQL SERVER – Index Seek vs. Index Scan – Diffefence and Usage – A Simple Note oracle表访问方式 Index Seek和Index Scan的区别以及适用情况 1.oracle中的表访问方式 在oracle中有表访问方式的说法,访问表中的数据主要通过三种方式进行访问: 全表扫描(full table scan),直接访问数据页,查找

MySQL Study之--Index的强制使用和忽略

MySQL Study之--Index的强制使用和忽略 1.查看表结构 mysql> show create table emp\G *************************** 1. row *************************** Table: emp Create Table: CREATE TABLE `emp` (   `empno` int(4) NOT NULL DEFAULT '0',   `ENAME` varchar(10) DEFAULT NULL,

index seek与index scan

低效 Index Scan(索引扫描):就全扫描索引(包括根页,中间页和叶级页): 高效 Index Seek(索引查找):通过索引向前和向后搜索 : 解释解释index seek和index scan: 索引是一颗B树, index seek是查找从B树的根节点开始,一级一级找到目标行. index scan则是从左到右,把整个B树遍历一遍. 假设唯一的目标行位于索引树最右的叶节点上(假设是非聚集索引,树深度2,叶节点占用k页物理存储). index seek引起的IO是4,而index sc

MySQL索引的Index method中btree和hash的优缺点

MySQL索引的Index method中btree和hash的区别 在MySQL中,大多数索引(如 PRIMARY KEY,UNIQUE,INDEX和FULLTEXT)都是在BTREE中存储,但使用memory引擎可以选择BTREE索引或者HASH索引,两种不同类型的索引各自有其不同的使用范围. Hash 索引结构的特殊性,其检索效率非常高,索引的检索可以一次定位,不像B-Tree 索引需要从根节点到枝节点,最后才能访问到页节点这样多次的IO访问,所以 Hash 索引的查询效率要远高于 B-T