MySQL子查询优化 -- FirstMatch策略

FirstMatch执行semi-join子查询的一种策略。

类似于MySQL 5.x中如何执行in、exists子查询。

让我们以搜索拥有大城市的国家为例:

select * from Country
where Country.code IN (select City.Country
                       from City
                       where City.Population > 1*1000*1000)
      and Country.continent=‘Europe‘;

假设,我们的执行计划是找到欧洲的国家,然后,对于每个找到的国家,检查它是否有大城市。常规的inner join执行将如下所示:

由于德国有两个大城市(在该图中),所以它将被两次放入查询输出中。这是不正确的,select … from country不应产生相同的国家记录两次。First Match策略在找到第一个真正的匹配后,通过缩短执行来避免产生重复:

注意,在应用了“Using where”之后,才进行short-cutting操作。在找到Tirer之后就进行short-cutting操作肯定是错误的。

上面的查询使用First Match之后,执行计划类似如下:

MariaDB [world]> explain select * from Country  where Country.code IN (select City.Country from City where City.Population > 1*1000*1000) and Country.continent=‘Europe‘;
+----+-------------+---------+------+--------------------+-----------+---------+--------------------+------+----------------------------------+
| id | select_type | table   | type | possible_keys      | key       | key_len | ref                | rows | Extra                            |
+----+-------------+---------+------+--------------------+-----------+---------+--------------------+------+----------------------------------+
|  1 | PRIMARY     | Country | ref  | PRIMARY,continent  | continent | 17      | const              |   60 | Using index condition            |
|  1 | PRIMARY     | City    | ref  | Population,Country | Country   | 3       | world.Country.Code |   18 | Using where; FirstMatch(Country) |
+----+-------------+---------+------+--------------------+-----------+---------+--------------------+------+----------------------------------+
2 rows in set (0.00 sec)

extra列中的FirstMatch(Country)表示,一旦生成了一个匹配的记录组合,就可以short-cutting过程就执行并跳转回Country表。

FirstMatch的查询计划与MySQL中的非常相似:

MySQL [world]> explain select * from Country  where Country.code IN (select City.Country from City where City.Population > 1*1000*1000) and Country.continent=‘Europe‘;
+----+--------------------+---------+----------------+--------------------+-----------+---------+-------+------+------------------------------------+
| id | select_type        | table   | type           | possible_keys      | key       | key_len | ref   | rows | Extra                              |
+----+--------------------+---------+----------------+--------------------+-----------+---------+-------+------+------------------------------------+
|  1 | PRIMARY            | Country | ref            | continent          | continent | 17      | const |   60 | Using index condition; Using where |
|  2 | DEPENDENT SUBQUERY | City    | index_subquery | Population,Country | Country   | 3       | func  |   18 | Using where                        |
+----+--------------------+---------+----------------+--------------------+-----------+---------+-------+------+------------------------------------+
2 rows in set (0.01 sec)

  

FirstMatch策略背后的思想和in->exists转换思想相同。然而,FirstMatch有以下的优点:
1.等价传播可以跨越semi-join边界,但是不能跨越子查询边界。因此,使用FirstMatch将子查询转换成semi-join可以提供一个更好的执行计划
2.只有一种方式使用in->exists策略,mysql会无条件地使用。对于FirstMatch策略,优化器可以选择是否应该在子查询中使用的所有表都位于join前缀时运行FirstMatch策略,或者在稍后的某个时间点运行FirstMatch策略

FirstMatch策略意味着子查询的表必须在父查询中的表之后被引用;
FirstMatch支持相关子查询;
不能应用于子查询带有group by或聚合函数的场景;
是否开启FirstMatch是由系统变量optimizer_switch中的firstmatch=on|off设置的。

https://mariadb.com/kb/en/library/firstmatch-strategy/

原文地址:https://www.cnblogs.com/abclife/p/10895624.html

时间: 2024-10-14 11:25:00

MySQL子查询优化 -- FirstMatch策略的相关文章

mysql 子查询优化一例

写在前面的话: 在慢查优化1和2里都反复强调过 explain 的重要性,但有时候肉眼看不出 explain 结果如何指导优化,这时候还需要有一些其他基础知识的佐助,甚至需要了解 MySQL 实现原理,如子查询慢查优化. 看到 SQL 执行计划中 select_type 字段中出现"DEPENDENT SUBQUERY"时,要打起精神了! --MySQL 的子查询为什么有时候很糟糕-- 引子:这样的子查询为什么这么慢? 下面的例子是一个慢查,线上执行时间相当夸张.为什么呢? SELEC

mysql 子查询优化

今天用到要查询七天内都没有装机的门店信息,首先想到了用not in,先把装机的userid查出来,然后再id not in,但是这样就必须使用子查询,数据量少还可以,数据量大了的话,肯定效率特别低,因为MySQL需要为内层查询语句的查询结果建立一个临时表.然后外层查询语句再临时表中查询记录.查询完毕后,MySQL需要撤销这些临时表.因此,子查询的速度会受到一定的影响.如果查询的数据量比较大,这种影响就会随之增大. 首先使用: select * from v9_wba_account where

【MySQL】MySQL中针对大数据量常用技术_创建索引+缓存配置+分库分表+子查询优化(转载)

原文地址:http://blog.csdn.net/zwan0518/article/details/11972853 目录(?)[-] 一查询优化 1创建索引 2缓存的配置 3slow_query_log分析 4分库分表 5子查询优化 二数据转移 21插入数据 如今随着互联网的发展,数据的量级也是撑指数的增长,从GB到TB到PB.对数据的各种操作也是愈加的困难,传统的关系性数据库已经无法满足快速查询与插入数据的需求.这个时候NoSQL的出现暂时解决了这一危机.它通过降低数据的安全性,减少对事务

mysql子查询慢的问题

当你在用explain工具查看sql语句的执行计划时,若select_type 字段中出现"DEPENDENT SUBQUERY"时,你要注意了,你已经掉入了mysql子查询慢的"坑"...下面我们来看一个具体的例子 有这样一条查询语句: SELECT gid,COUNT(id) as count FROM shop_goods g1 WHERE status =0 and gid IN (SELECT gid FROM shop_goods g2 WHERE si

MySQL子查询慢现象的解决

当你在用explain工具查看sql语句的执行计划时,若select_type 字段中出现“DEPENDENT SUBQUERY”时,你要注意了,你已经掉入了mysql子查询慢的“坑". 相关书籍:高性能MySQL(第3版) 中文PDF带目录清晰版 http://www.linuxidc.com/Linux/2014-10/108464.htm 下面我们来看一个具体的例子 有这样一条查询语句: SELECT gid,COUNT(id) as count FROM shop_goods g1 WH

MySQL 慢查询优化

为什么查询速度会慢 1.慢是指一个查询的响应时间长.一个查询的过程: 客户端发送一条查询给服务器 服务器端先检查查询缓存,如果命中了缓存,则立可返回存储在缓存中的结果.否则进入下一个阶段 服务器端进行SQL解析.预处理,再由优化器生成对应的执行计划. MySQL根据优化器生成的执行计划,调用存储引擎的API来执行查询. 将结果返回给客户端 2.数据访问 是否向数据库请求了不需要的数据 是否扫描额外的记录 3.查询的方式 一个复杂的查询还是多个简单的查询 切分查询(将大查询切分成小查询,循环完成小

Mysql——子查询

子查询的位置: select 中.from 后.where 中.group by 和order by 中无实用意义. 子查询分为如下几类: 1,标量子查询:返回单一值的标量,最简单的形式. 2,列子查询:返回的结果集是 N 行一列. 3,行子查询:返回的结果集是一行 N 列. 4,表子查询:返回的结果集是 N 行 N 列. 可以使用的操作符:= > < >= <= <> ANY IN SOME ALL EXISTS 标量子查询:是指子查询返回的是单一值的标量,如一个数字

MySQL子查询的优化

一.MySQL子查询的位置 当一个查询是另一个查询的子部分是,称之为子查询(查询语句中嵌套含有查询语句).子查询也是使用频率比较高的一种查询类型.因此,优化子查询,对于整个系统的性能也有直接的影响. 从查询出现在SQL语句的位置来看,它可以出现在目标列中,也可以出现在from子句中,还可以出现在JOIN/ON子句.GROUPBY子句.HAVING子句.ORDERBY子句等位置.下面依次来看这几种形式的子查询,以及对他们进行优化的一些想法. 1.子查询出现在目标列位置 当子查询出现在目标列位置的时

由一条sql语句想到的子查询优化

摘要:相信大家都使用过子查询,因为使用子查询可以一次性的完成很多逻辑上需要多个步骤才能完成的SQL操作,比较灵活,我也喜欢用,可最近因为一条包含子查询的select count(*)语句导致点开管理系统的一个功能模块列表时,耗时44几秒,到了不可容忍的地步,定位发现是因为未加索引和用了子查询导致,不加索引导致查询慢好理解,但子查询也会引起查询效率过低吗?没错,所以本文就以这次案例来重新认识下MySQL子查询. 特别说明:本文介绍的是在MySQL5.5.6版本下子查询的案例,5.5.29版本的我也