MySQL 5.6 查询优化器改进

一.ICP

注意一下ICP的使用条件:

  1. 只能用于二级索引(secondary index)。
  2. explain显示的执行计划中type值(join 类型)为range、 ref、 eq_ref或者ref_or_null。且查询需要访问表的整行数据,即不能直接通过二级索引的元组数据获得查询结果(索引覆盖)。
  3. ICP可以用于MyISAM和InnnoDB存储引擎,不支持分区表(5.7将会解决这个问题)。

二.order by ..  limit ...优化

from mysql 5.6.2 开始对order by ..  limit ...优化:

select col1,col2 from tx order by no_key_col limit offset,rowcount;

From 5.6.2 by treating the sort buffer as a priority queue:

  • Scan the table, inserting the select list columns from each selected row in sorted order in the queue. If the queue is full, bump out the last row in the sort order.
  • Return the first N rows from the queue. (If M was specified, skip the first M rows and return the next N rows.)

Before 5.6.2,Previously, the server performed this operation by using a merge file for the sort:

  • Scan the table, repeating these steps through the end of the table:

    • Select rows until the sort buffer is filled.
    • Write the first N rows in the buffer (M+N rows if M was specified) to a merge file.
  • Sort the merge file and return the first N rows. (If M was specified, skip the first M rows and return the next N rows.)

The cost of the table scan is the same for the queue and merge-file methods, so the optimizer chooses between methods based on other costs:

  • The queue method involves more CPU for inserting rows into the queue in order
  • The merge-file method has I/O costs to write and read the file and CPU cost to sort it

算法:

5.6使用queue:

把select 的列放入队列里,当队列满了把队列最后的出队列,就是把最大的、次大的、.....依次推到队列的前面,表所有行的列全部放完后,把第一个前rowcount 出队列,依次进行,都在sort buffer 里排序。

5.6之前:使用 merge file

把row insert 到 sort buffer,sort buffer相当于一个堆栈,sort buffer被插满了,依次把当前堆栈里前面的rowcount出队列放入到merge file,直到所有的排好序,然后通过merge file 再排序取出结果。

后续 ...........................

时间: 2024-10-09 12:05:45

MySQL 5.6 查询优化器改进的相关文章

结合mysql查询优化器对联合索引的探讨

无陈述,直接开讲: babysitter_account表中的联合索引如下(开发小伙伴们自建的联合索引.您发现不妥了吗?): KEY `flag` (`flag`,`user_id`,`account_id`) 过去认为: 1.SELECT account_id,weibo_id,weibo_type FROM babysitter_account WHERE user_id BETWEEN 100 and 10000 AND flag=0; 2.SELECT account_id,weibo_

Mysql查询优化器浅析

--Mysql查询优化器浅析 -----------------------------2014/06/11 1 定义 Mysql查询优化器的工作是为查询语句选择合适的执行路径.查询优化器的代码一般是经常变动的,这和存储引擎不太一样.因此,需要理解最新版本的查询优化器是如何组织的,请参考相应的源代码.整体而言,优化器有很多相同性,对mysql一个版本的优化器做到整体掌握,理解起mysql新版本以及其他数据库的优化器都是类似的. 优化器会对查询语句进行转化,转化等价的查询语句.举个例子,优化器会将

Atitit Mysql查询优化器 存取类型 范围存取类型 索引存取类型 AND or的分析

    Atitit Mysql查询优化器 存取类型 范围存取类型 索引存取类型 AND or的分析1 存取类型1 5         范围存取类型2 6         索引存取类型2 7         转换3 AND3 9         OR3 10    UNION3 11    NOT,<>4 12    ORDER BY4 13    GROUP BY4 存取类型 当我们评估一个条件表达式,MySQL判断该表达式的存取类型.下面是一些存取类型,按照从最优到最差的顺序进行排列: s

Mysql查询优化器

本文的目的主要是通过告诉大家,查询优化器为我们做了那些工作,我们怎么做,才能使查询优化器对我们的sql进行优化,以及启示我们sql语句怎么写,才能更有效率.那么到底mysql到底能进行哪些优化那,下面通过以下几个方面来探讨一下: 1.常量转化 它能够对sql语句中的常量进行转化,比如下面的表达式: WHERE col1 = col2 AND col2 = 'x'; 依据传递性:如果A=B and B=C,那么就能得出A=C.所以上面的表达式mysql查询优化器能进行如下的优化:WHERE col

1025WHERE执行顺序以及MySQL查询优化器

转自http://blog.csdn.net/zhanyan_x/article/details/25294539 -- WHERE执行顺序-- 过滤比较多的放在前面,然后更加容易匹配,从左到右进行执行:一般都是优化器很智能的优化了,无需用户处理-- 如何查看优化后的语句EXPLAIN EXTENDEDSELECT SQL_NO_CACHE * FROM db.tableWHERE is_day=1 AND DATE(ex_date)='2015-07-01' ; SHOW WARNINGS;

MySQL查询优化器工作原理解析

手册上查询优化器概述 查询优化器的任务是发现执行SQL查询的最佳方案.大多数查询优化器,包括MySQL的查询优化器,总或多或少地在所有可能的查询评估方案中搜索最佳方案.对于联接查询,MySQL优化器所调查的可能的方案数随查询中所引用的表的数目呈指数增长.对于小数量的表(典型小于7-10),这不是一个问题.然而,当提交的查询更大时,查询优化所花的时间会很容易地成为服务器性能的主要瓶颈. 查询优化的一个更加灵活的方法是允许用户控制优化器详尽地搜索最佳查询评估方案.一般思想是优化器调查的方案越少,它编

010 --MySQL查询优化器的局限性

MySQL的万能"嵌套循环"并不是对每种查询都是最优的.不过还好,mysql查询优化器只对少部分查询不适用,而且我们往往可以通过改写查询让mysql高效的完成工作.在这我们先来看看mysql优化器有哪些局限性: 1.关联子查询 mysql的子查询实现得非常糟糕.最糟糕得一类查询是where条件中包含in()的子查询语句.例如,我们希望找到sakila数据库中,演员Penlope Guiness参演的所有影片信息.很自然的,我们会按照下面的方式用子查询实现: select * from

mysql 索引和查询优化

对于任何DBMS,索引都是进行优化的最主要的因素.对于少量的数据,没有合适的索引影响不是很大,但是,当随着数据量的增加,性能会急剧下降.如果对多列进行索引(组合索引),列的顺序非常重要,MySQL仅能对索引最左边的前缀进行有效的查找. 例如:假 设存在组合索引it1c1c2(c1,c2),查询语句select * from t1 where c1=1 and c2=2能够使用该索引.查询语句select * from t1 where c1=1也能够使用该索引.但是,查询语句select * f

MySQL索引及查询优化总结

作者 | 谢庆玲 文章<MySQL查询分析>讲述了使用MySQL慢查询和explain命令来定位mysql性能瓶颈的方法,定位出性能瓶颈的sql语句后,则需要对低效的sql语句进行优化.本文主要讨论MySQL索引原理及常用的sql查询优化. 一个简单的对比测试 前面的案例中,c2c_zwdb.t_file_count表只有一个自增id,FFileName字段未加索引的sql执行情况如下: 在上图中,type=all,key=null,rows=33777.该sql未使用索引,是一个效率非常低的