MySQL索引条件下推的简单测试

自MySQL 5.6开始,在索引方面有了一些改进,比如索引条件下推(Index condition pushdown,ICP),严格来说属于优化器层面的改进。

如果简单来理解,就是优化器会尽可能的把index
condition的处理从Server层下推到存储引擎层。举一个例子,有一个表中含有组合索引idx_cols包含(c1,c2,…,cn)n个列,如果在c1上存在范围扫描的where条件,那么剩余的c2,…,cn这n-1个上索引都无法用来提取和过滤数据,而ICP就是把这个事情优化一下。

我们在MySQL 5.6的环境中来简单测试一下。

我们创建表emp,含有一个主键,一个组合索引来说明一下。

create table emp(
empno smallint(5) unsigned not null auto_increment,
ename varchar(30) not null,
deptno smallint(5) unsigned not null,
job varchar(30) not null,
primary key(empno),
key idx_emp_info(deptno,ename)
)engine=InnoDB charset=utf8;

当然我也随机插入了几条数据,意思一下。

insert into emp values(1,'zhangsan',1,'CEO'),(2,'lisi',2,'CFO'),(3,'wangwu',3,'CTO'),(4,'jeanron100',3,'Enginer');

ICP的控制在数据库参数中有一个优化器参数optimizer_switch来统一管理,我想这也是MySQL优化器离我们最贴近的时候了。可以使用如下的方式来查看。

show variables like 'optimizer_switch';

当然在5.6以前的版本中,你是看不到index condition pushdown这样的字样的。在5.6版本中查看到的结果如下:

# mysqladmin var|grep optimizer_switch
optimizer_switch                                       |
index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,engine_condition_pushdown=on,index_condition_pushdown=on,mrr=on,mrr_cost_based=on,block_nested_loop=on,batched_key_access=off,materialization=on,semijoin=on,loosescan=on,firstmatch=on,subquery_materialization_cost_based=on,use_index_extensions=on下面我们就用两个语句来对比说明一下,就通过执行计划来对比。

set optimizer_switch = "index_condition_pushdown=off"

> explain select  *   from emp  where deptno between 1 and 100 and ename ='jeanron100';
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra       |
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+
|  1 | SIMPLE      | emp   | ALL  | idx_emp_info  | NULL | NULL    | NULL |    4 | Using where |
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+

而如果开启,看看ICP是否启用。
set optimizer_switch = "index_condition_pushdown=on";> explain select  *   from emp  where deptno between 10 and 3000 and ename ='jeanron100';
+----+-------------+-------+-------+---------------+--------------+---------+------+------+-----------------------+
| id | select_type | table | type  | possible_keys | key          | key_len | ref  | rows | Extra                 |
+----+-------------+-------+-------+---------------+--------------+---------+------+------+-----------------------+
|  1 | SIMPLE      | emp   | range | idx_emp_info  | idx_emp_info | 94      | NULL |    1 | Using index condition |
+----+-------------+-------+-------+---------------+--------------+---------+------+------+-----------------------+
1 row in set (0.00 sec)如果你观察仔细,会发现两次的语句还是不同的,那就是范围扫描的范围不同,如果还是用原来的语句,结果还是有一定的限制的。

> explain select  *   from emp  where deptno between 1 and 300 and ename ='jeanron100';
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra       |
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+
|  1 | SIMPLE      | emp   | ALL  | idx_emp_info  | NULL | NULL    | NULL |    4 | Using where |
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+
1 row in set (0.00 sec)这个地方就值得好好推敲了。

时间: 2024-10-26 13:27:23

MySQL索引条件下推的简单测试的相关文章

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

原文:浅析MySQL中的Index Condition Pushdown (ICP 索引条件下推)和Multi-Range Read(MRR 索引多范围查找)查询优化   本文出处:http://www.cnblogs.com/wy123/p/7374078.html(保留出处并非什么原创作品权利,本人拙作还远远达不到,仅仅是为了链接到原文,因为后续对可能存在的一些错误进行修正或补充,无他)     ICP优化原理 Index Condition Pushdown (ICP),也称为索引条件下推

mysql (ICP) 索引条件下推对比ORACLE进行说明

mysql (ICP) 索引条件下推对比ORACLE进行说明 第一次看到这个名词,与ORACLE FPD - filter push-down想到了一块,但是后来才发现他们根本同一个东西, 简单的收ICP就是当索引包含所有的访问字段的时候,可以在根据前导列过滤掉条件的时候,同时过滤掉另外的 条件,比如说 CREATE TABLE TESTICP(A INT,B INT,C NAME); ALTER TABLE TESTTICP ADD KEY(A,B); SELECT * FROM TESTIC

mysql数据库的MEMORY引擎简单测试

存储在内存中,默认使用哈希索引(InnoDB为B树索引).速度很快,但服务器关闭后数据全部丢失,仅保存.frm表定义文件. 在一万条数据的情况下,针对MyISAM和Memory粗略地进行测试,MyISAM全表扫描花了360ms,Memory则只需要10ms. 重启服务器后,memory表数据全部丢失,但是表仍然存在. 注意事项: ·不支持BLOB和TEXT类型 ·使用固定长度行存储格式,因此varchar会被转换成char ·max_heap_table_size参数决定了Memory表的最大占

MySQL · 性能优化 · 条件下推到物化表

背景 MySQL引入了Materialization(物化)这一关键特性用于子查询(比如在IN/NOT IN子查询以及 FROM 子查询)优化. 具体实现方式是:在SQL执行过程中,第一次需要子查询结果时执行子查询并将子查询的结果保存为临时表 ,后续对子查询结果集的访问将直接通过临时表获得. 与此同时,优化器还具有延迟物化子查询的能力,先通过其它条件判断子查询是否真的需要执行.物化子查询优化SQL执行的关键点在于对子查询只需要执行一次. 与之相对的执行方式是对外表的每一行都对子查询进行调用,其执

mysql convert函数性能简单测试

得到了这样一个需求,需要按照拼音字母排序,而mysql数据库使用的是utf编码. 如果使用gbk的话,排序规则是按拼音的. 而mysql中convert函数,可以对数据进行转换. 我们对这个convert进行了简单的性能测试,下面介绍一下测试过程,以及测试结果,如有问题,请各位指出. 软硬件环境 硬件配置:2核CPU.2G内存 数据库:Mysql 5.5 表结构 1 2 3 4 5 CREATE TABLE `test_gbk` ( `id` int(11) NOT NULL AUTO_INCR

MySQL Profile在5.7的简单测试

MySQL Profile对于分析执行计划的开销来说,还是有一定的帮助,至少在分析一些性能问题的时候有很多的参考依据. 我在5.6, 5.7版本中进行了测试,没发现差别,还是以5.7为例进行演示吧. mysql> select version(); +-----------+ | version() | +-----------+ | 5.7.10    | +-----------+ 1 row in set (0.00 sec) 传统的使用Profile都是使用show profile这样的

深入分析MySQL索引结构原理、性能分析与优化详解

第一部分:基础知识: 索引 官方介绍索引是帮助MySQL高效获取数据的数据结构.笔者理解索引相当于一本书的目录,通过目录就知道要的资料在哪里,不用一页一页查阅找出需要的资料.关键字index --------------------- 唯一索引 强调唯一,就是索引值必须唯一,关键字unique index 创建索引: 1.create unique index 索引名 on 表名(列名); 2.alter table 表名 add unique index 索引名 (列名); 删除索引: 1.

MySQL索引及查询优化总结 专题

  小结:db名与应用名相同,表名:业务名_此表的作用 ,表名表示内容,不体现数量,如果表示boolean概念,表名需要使用is_业务含义来表示,但POJO中不应该出现isXXX,因为不方便序列化,中间的对应关系,使用ResultMap来映射字段名中有多个单词,使用下划线连接,字段名不能以数字打着,数字和单词之间,只需要一个下划线,譬如xx_3xx,不建议写成xx_3_xx最左前缀原则    如果是联合索引,Btree索引在使用时受索引建立的字段顺序的影响where条件中有or,建议拆成unio

MySQL索引 专题

什么是索引 索引是存储引擎用于快速找到记录的一种数据结构,索引类似一本书的目录,我们可以快速的根据目录查找到我们想要的内容的所在页码,索引的优化应该是对查询性能优化最有效的手段了. 因此,首先你要明白的一点就是,索引它也是一个文件,它是要占据物理空间的. Digest: 索引在文件系统中的体现: 1. 索引是按照特定的数据结构把数据表中的数据放在索引文件中,以便于快速查找: 2. 索引存在于磁盘中,会占据物理空间.因此不恰当的索引会影响性能 存储引擎与索引类型的区别: 1. 不同的存储引擎可能支