扫码关注官方微信

扫码下载APP
返回顶部
首页 > 资讯 > 数据库 >MySQL之select in 子查询优化的实现
  • 108

0
分享到

MySQL之select in 子查询优化的实现

MySQLselectin子查询MySQLselectinMySQL子查询 2022-05-13 01:05:03 108人浏览 独家记忆
摘要

下面的演示基于Mysql5.7.27版本 一、关于mysql子查询的优化策略介绍: 子查询优化策略 对于不同类型的子查询，优化器会选择不同的策略。 对于 IN、=ANY 子查询，优化器有如下策略选择： s

下面的演示基于Mysql5.7.27版本

一、关于mysql子查询的优化策略介绍:

子查询优化策略

对于不同类型的子查询，优化器会选择不同的策略。

对于 IN、=ANY 子查询，优化器有如下策略选择：

  • semijoin
  • Materialization
  • exists

对于 NOT IN、<>ALL 子查询，优化器有如下策略选择：

  • Materialization
  • exists

对于 derived 派生表，优化器有如下策略选择：
derived_merge，将派生表合并到外部查询中（5.7 引入 ）；
将派生表物化为内部临时表，再用于外部查询。
注意：update 和 delete 语句中子查询不能使用 semijoin、materialization 优化策略

二、创建数据进行模拟演示

为了方便分析问题先建两张表并插入模拟数据：


CREATE TABLE `test02` (
 `id` int(11) NOT NULL,
 `a` int(11) DEFAULT NULL,
 `b` int(11) DEFAULT NULL,
 PRIMARY KEY (`id`),
 KEY `a` (`a`)
) ENGINE=InnoDB;

drop procedure idata;
delimiter ;;
create procedure idata()
begin
 declare i int;
 set i=1;
 while(i<=10000)do
  insert into test02 values(i, i, i);
  set i=i+1;
 end while;
end;;
delimiter ;
call idata();

create table test01 like test02;
insert into test01 (select * from test02 where id<=1000)

三、举例分析SQL实例

子查询示例：


SELECT * FROM test01 WHERE test01.a IN (SELECT test02.b FROM test02 WHERE id < 10)

大部分人可定会简单的认为这个 sql 会这样执行：


SELECT test02.b FROM test02 WHERE id < 10

结果:1,2,3,4,5,6,7,8,9


SELECT * FROM test01 WHERE test01.a IN (1,2,3,4,5,6,7,8,9);

但实际上 MySQL 并不是这样做的。MySQL 会将相关的外层表压到子查询中，优化器认为这样效率更高。也就是说，优化器会将上面的 SQL 改写成这样：


select * from test01 where exists(select b from test02 where id < 10 and test01.a=test02.b);

提示： 针对mysql5.5以及之前的版本

查看执行计划如下，发现这条SQL对表test01进行了全表扫描1000，效率低下：


root@localhost [dbtest01]>desc select * from test01 where exists(select b from test02 where id < 10 and test01.a=test02.b);
+----+--------------------+--------+------------+-------+---------------+---------+---------+------+--------+----------+-------------+
| id | select_type    | table | partitions | type | possible_keys | key   | key_len | ref | rows  | filtered | Extra    |
+----+--------------------+--------+------------+-------+---------------+---------+---------+------+--------+----------+-------------+
| 1 | PRIMARY      | test01 | NULL    | ALL  | NULL     | NULL  | NULL  | NULL | 1000  |  100.00 | Using where |
| 2 | DEPENDENT SUBQUERY | test02 | NULL    | range | PRIMARY    | PRIMARY | 4    | NULL |   9 |  10.00 | Using where |
+----+--------------------+--------+------------+-------+---------------+---------+---------+------+--------+----------+-------------+
2 rows in set, 2 warnings (0.00 sec)

但是此时实际执行下面的SQL，发现也不慢啊,这不是自相矛盾嘛，别急，咱们继续往下分析:


SELECT * FROM test01 WHERE test01.a IN (SELECT test02.b FROM test02 WHERE id < 10)

查看此条SQL的执行计划如下：


root@localhost [dbtest01]>desc SELECT * FROM test01 WHERE test01.a IN (SELECT test02.b FROM test02 WHERE id < 10);
+----+--------------+-------------+------------+-------+---------------+---------+---------+---------------+------+----------+-------------+
| id | select_type | table    | partitions | type | possible_keys | key   | key_len | ref      | rows | filtered | Extra    |
+----+--------------+-------------+------------+-------+---------------+---------+---------+---------------+------+----------+-------------+
| 1 | SIMPLE    | <subquery2> | NULL    | ALL  | NULL     | NULL  | NULL  | NULL     | NULL |  100.00 | Using where |
| 1 | SIMPLE    | test01   | NULL    | ref  | a       | a    | 5    | <subquery2>.b |  1 |  100.00 | NULL    |
| 2 | MATERIALIZED | test02   | NULL    | range | PRIMARY    | PRIMARY | 4    | NULL     |  9 |  100.00 | Using where |
+----+--------------+-------------+------------+-------+---------------+---------+---------+---------------+------+----------+-------------+
3 rows in set, 1 warning (0.00 sec)

发现优化器使用到了策略MATERIALIZED。于是对此策略进行了资料查询和学习。
https://dev.mysql.com/doc/refman/5.6/en/subquery-optimization.html

原因是从MySQL5.6版本之后包括MySQL5.6版本，优化器引入了新的优化策略:materialization=[off|on],semijoin=[off|on],(off代表关闭此策略，on代表开启此策略)
可以采用show variables like 'optimizer_switch'; 来查看MySQL采用的优化器策略。当然这些策略都是可以在线进行动态修改的
set global optimizer_switch='materialization=on,semijoin=on';代表开启优化策略materialization和semijoin

MySQL5.7.27默认的优化器策略：


root@localhost [dbtest01]>show variables like 'optimizer_switch';                                                               
+------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Variable_name  | Value                                                                                                                                                                                                      |
+------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| 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,duplicateweedout=on,subquery_materialization_cost_based=on,use_index_extensions=on,condition_fanout_filter=on,derived_merge=on |
+------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

所以在MySQL5.6及以上版本时

执行下面的SQL是不会慢的。因为MySQL的优化器策略materialization和semijoin 对此SQL进行了优化


SELECT * FROM test01 WHERE test01.a IN (SELECT test02.b FROM test02 WHERE id < 10)

然而咱们把mysql的优化器策略materialization和semijoin 关闭掉测试，发现SQL确实对test01进行了全表的扫描(1000):


set global optimizer_switch='materialization=off,semijoin=off';

执行计划如下test01表确实进行了全表扫描:


root@localhost [dbtest01]>desc SELECT * FROM test01 WHERE test01.a IN (SELECT test02.b FROM test02 WHERE id < 10);
+----+--------------------+--------+------------+-------+---------------+---------+---------+------+--------+----------+-------------+
| id | select_type    | table | partitions | type | possible_keys | key   | key_len | ref | rows  | filtered | Extra    |
+----+--------------------+--------+------------+-------+---------------+---------+---------+------+--------+----------+-------------+
| 1 | PRIMARY      | test01 | NULL    | ALL  | NULL     | NULL  | NULL  | NULL | 1000  |  100.00 | Using where |
| 2 | DEPENDENT SUBQUERY | test02 | NULL    | range | PRIMARY    | PRIMARY | 4    | NULL |   9 |  10.00 | Using where |
+----+--------------------+--------+------------+-------+---------------+---------+---------+------+--------+----------+-------------+
2 rows in set, 1 warning (0.00 sec)

下面咱们分析下这个执行计划:

！！！！再次提示:如果是mysql5.5以及之前的版本，或者是mysql5.6以及之后的版本关闭掉优化器策略materialization=off,semijoin=off，得到的SQL执行计划和下面的是相同的


root@localhost [dbtest01]>desc select * from test01 where exists(select b from test02 where id < 10 and test01.a=test02.b);
+----+--------------------+--------+------------+-------+---------------+---------+---------+------+------+----------+-------------+
| id | select_type    | table | partitions | type | possible_keys | key   | key_len | ref | rows | filtered | Extra    |
+----+--------------------+--------+------------+-------+---------------+---------+---------+------+------+----------+-------------+
| 1 | PRIMARY      | test01 | NULL    | ALL  | NULL     | NULL  | NULL  | NULL | 1000 |  100.00 | Using where |
| 2 | DEPENDENT SUBQUERY | test02 | NULL    | range | PRIMARY    | PRIMARY | 4    | NULL |  9 |  10.00 | Using where |
+----+--------------------+--------+------------+-------+---------------+---------+---------+------+------+----------+-------------+
2 rows in set, 2 warnings (0.00 sec)

不相关子查询变成了关联子查询（select_type:DEPENDENT SUBQUERY），子查询需要根据 b 来关联外表 test01，因为需要外表的 test01 字段，所以子查询是没法先执行的。执行流程为：

  1. 扫描 test01，从 test01 取出一行数据 R；
  2. 从数据行 R 中，取出字段 a 执行子查询，如果得到结果为 TRUE，则把这行数据 R 放到结果集；
  3. 重复 1、2 直到结束。

总的扫描行数为 1000+1000*9=10000（这是理论值，但是实际值比10000还少，怎么来的一直没想明白，看规律是子查询结果集每多一行，总扫描行数就会少几行）。

Semi-join优化器:

这样会有个问题，如果外层表是一个非常大的表，对于外层查询的每一行，子查询都得执行一次，这个查询的性能会非常差。我们很容易想到将其改写成 join 来提升效率：


select test01.* from test01 join test02 on test01.a=test02.b and test02.id<10;

# 查看此SQL的执行计划:


desc select test01.* from test01 join test02 on test01.a=test02.b and test02.id<10;

root@localhost [dbtest01]>EXPLaiN extended select test01.* from test01 join test02 on test01.a=test02.b and test02.id<10;
+----+-------------+--------+------------+-------+---------------+---------+---------+-------------------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key   | key_len | ref        | rows | filtered | Extra    |
+----+-------------+--------+------------+-------+---------------+---------+---------+-------------------+------+----------+-------------+
| 1 | SIMPLE   | test02 | NULL    | range | PRIMARY    | PRIMARY | 4    | NULL       |  9 |  100.00 | Using where |
| 1 | SIMPLE   | test01 | NULL    | ref  | a       | a    | 5    | dbtest01.test02.b |  1 |  100.00 | NULL    |
+----+-------------+--------+------------+-------+---------------+---------+---------+-------------------+------+----------+-------------+
2 rows in set, 2 warnings (0.00 sec)

这样优化可以让 t2 表做驱动表，t1 表关联字段有索引，查找效率非常高。

但这里会有个问题，join 是有可能得到重复结果的，而 in(select ...) 子查询语义则不会得到重复值。
而 semijoin 正是解决重复值问题的一种特殊联接。
在子查询中，优化器可以识别出 in 子句中每组只需要返回一个值，在这种情况下，可以使用 semijoin 来优化子查询，提升查询效率。
这是 MySQL 5.6 加入的新特性，MySQL 5.6 以前优化器只有 exists 一种策略来“优化”子查询。

经过 semijoin 优化后的 SQL 和执行计划分为：


root@localhost [dbtest01]>desc SELECT * FROM test01 WHERE test01.a IN (SELECT test02.b FROM test02 WHERE id < 10);
+----+--------------+-------------+------------+-------+---------------+---------+---------+---------------+------+----------+-------------+
| id | select_type | table    | partitions | type | possible_keys | key   | key_len | ref      | rows | filtered | Extra    |
+----+--------------+-------------+------------+-------+---------------+---------+---------+---------------+------+----------+-------------+
| 1 | SIMPLE    | <subquery2> | NULL    | ALL  | NULL     | NULL  | NULL  | NULL     | NULL |  100.00 | Using where |
| 1 | SIMPLE    | test01   | NULL    | ref  | a       | a    | 5    | <subquery2>.b |  1 |  100.00 | NULL    |
| 2 | MATERIALIZED | test02   | NULL    | range | PRIMARY    | PRIMARY | 4    | NULL     |  9 |  100.00 | Using where |
+----+--------------+-------------+------------+-------+---------------+---------+---------+---------------+------+----------+-------------+
3 rows in set, 1 warning (0.00 sec)


select 
  `test01`.`id`,`test01`.`a`,`test01`.`b` 
from `test01` semi join `test02` 
where
  ((`test01`.`a` = `<subquery2>`.`b`) 
  and (`test02`.`id` < 10));

##注意这是优化器改写的SQL，客户端上是不能用 semi join 语法的

semijoin 优化实现比较复杂，其中又分 FirstMatch、Materialize 等策略,上面的执行计划中 select_type=MATERIALIZED 就是代表使用了 Materialize 策略来实现的 semijoin
这里 semijoin 优化后的执行流程为：

先执行子查询，把结果保存到一个临时表中，这个临时表有个主键用来去重；
从临时表中取出一行数据 R；
从数据行 R 中，取出字段 b 到被驱动表 t1 中去查找，满足条件则放到结果集；
重复执行 2、3，直到结束。
这样一来，子查询结果有 9 行，即临时表也有 9 行（这里没有重复值），总的扫描行数为 9+9+9*1=27 行，比原来的 10000 行少了很多。

MySQL 5.6 版本中加入的另一种优化特性 materialization，就是把子查询结果物化成临时表，然后代入到外查询中进行查找，来加快查询的执行速度。内存临时表包含主键（hash 索引），消除重复行，使表更小。
如果子查询结果太大，超过 tmp_table_size 大小，会退化成磁盘临时表。这样子查询只需要执行一次，而不是对于外层查询的每一行都得执行一遍。
不过要注意的是，这样外查询依旧无法通过索引快速查找到符合条件的数据，只能通过全表扫描或者全索引扫描，

semijoin 和 materialization 的开启是通过 optimizer_switch 参数中的 semijoin={on|off}、materialization={on|off} 标志来控制的。
上文中不同的执行计划就是对 semijoin 和 materialization 进行开/关产生的
总的来说对于子查询，先检查是否满足各种优化策略的条件（比如子查询中有 union 则无法使用 semijoin 优化）
然后优化器会按成本进行选择，实在没得选就会用 exists 策略来“优化”子查询，exists 策略是没有参数来开启或者关闭的。

下面举一个delete相关的子查询例子：

把上面的2张测试表分别填充350万数据和50万数据来测试delete语句


root@localhost [dbtest01]>select count(*) from test02;
+----------+
| count(*) |
+----------+
| 3532986 |
+----------+
1 row in set (0.64 sec)
root@localhost [dbtest01]>create table test01 like test02;
Query OK, 0 rows affected (0.01 sec)

root@localhost [dbtest01]>insert into test01 (select * from test02 where id<=500000)

root@localhost [dbtest01]>select count(*) from test01;
+----------+
| count(*) |
+----------+
|  500000 |

执行delete删除语句执行了4s


root@localhost [dbtest01]>delete FROM test01 WHERE test01.a IN (SELECT test02.b FROM test02 WHERE id < 10);
Query OK, 9 rows affected (4.86 sec)

查看 执行计划，对test01表进行了几乎全表扫描:


root@localhost [dbtest01]>desc delete FROM test01 WHERE test01.a IN (SELECT test02.b FROM test02 WHERE id < 10);
+----+--------------------+--------+------------+-------+---------------+---------+---------+------+--------+----------+-------------+
| id | select_type    | table | partitions | type | possible_keys | key   | key_len | ref | rows  | filtered | Extra    |
+----+--------------------+--------+------------+-------+---------------+---------+---------+------+--------+----------+-------------+
| 1 | DELETE       | test01 | NULL    | ALL  | NULL     | NULL  | NULL  | NULL | 499343 |  100.00 | Using where |
| 2 | DEPENDENT SUBQUERY | test02 | NULL    | range | PRIMARY    | PRIMARY | 4    | NULL |   9 |  10.00 | Using where |
+----+--------------------+--------+------------+-------+---------------+---------+---------+------+--------+----------+-------------+
2 rows in set (0.00 sec)

于是修改上面的delete SQL语句伪join语句


root@localhost [dbtest01]>desc delete test01.* from test01 join test02 on test01.a=test02.b and test02.id<10;
+----+-------------+--------+------------+-------+---------------+---------+---------+-------------------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key   | key_len | ref        | rows | filtered | Extra    |
+----+-------------+--------+------------+-------+---------------+---------+---------+-------------------+------+----------+-------------+
| 1 | SIMPLE   | test02 | NULL    | range | PRIMARY    | PRIMARY | 4    | NULL       |  9 |  100.00 | Using where |
| 1 | DELETE   | test01 | NULL    | ref  | a       | a    | 5    | dbtest01.test02.b |  1 |  100.00 | NULL    |
+----+-------------+--------+------------+-------+---------------+---------+---------+-------------------+------+----------+-------------+
2 rows in set (0.01 sec)

执行非常的快
root@localhost [dbtest01]>delete test01.* from test01 join test02 on test01.a=test02.b and test02.id<10;
Query OK, 9 rows affected (0.01 sec)

root@localhost [dbtest01]>select test01.* from test01 join test02 on test01.a=test02.b and test02.id<10;
Empty set (0.00 sec)

下面的这个表执行要全表扫描，非常慢，基本对表test01进行了全表扫描:


root@lcalhost [dbtest01]>desc delete FROM test01 WHERE id IN (SELECT id FROM test02 WHERE id='350000');
+----+--------------------+--------+------------+-------+---------------+---------+---------+-------+--------+----------+-------------+
| id | select_type    | table | partitions | type | possible_keys | key   | key_len | ref  | rows  | filtered | Extra    |
+----+--------------------+--------+------------+-------+---------------+---------+---------+-------+--------+----------+-------------+
| 1 | DELETE       | test01 | NULL    | ALL  | NULL     | NULL  | NULL  | NULL | 499343 |  100.00 | Using where |
| 2 | DEPENDENT SUBQUERY | test02 | NULL    | const | PRIMARY    | PRIMARY | 4    | const |   1 |  100.00 | Using index |
+----+--------------------+--------+------------+-------+---------------+---------+---------+-------+--------+----------+-------------+
2 rows in set (0.00 sec)

然而采用join的话，效率非常的高:


root@localhost [dbtest01]>desc delete test01.* FROM test01 inner join test02 WHERE test01.id=test02.id and test02.id=350000 ;
+----+-------------+--------+------------+-------+---------------+---------+---------+-------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key   | key_len | ref  | rows | filtered | Extra    |
+----+-------------+--------+------------+-------+---------------+---------+---------+-------+------+----------+-------------+
| 1 | DELETE   | test01 | NULL    | const | PRIMARY    | PRIMARY | 4    | const |  1 |  100.00 | NULL    |
| 1 | SIMPLE   | test02 | NULL    | const | PRIMARY    | PRIMARY | 4    | const |  1 |  100.00 | Using index |
+----+-------------+--------+------------+-------+---------------+---------+---------+-------+------+----------+-------------+
2 rows in set (0.01 sec)

 
root@localhost [dbtest01]> desc delete test01.* from test01 join test02 on test01.a=test02.b and test02.id=350000;
+----+-------------+--------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key   | key_len | ref  | rows | filtered | Extra |
+----+-------------+--------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
| 1 | SIMPLE   | test02 | NULL    | const | PRIMARY    | PRIMARY | 4    | const |  1 |  100.00 | NULL |
| 1 | DELETE   | test01 | NULL    | ref  | a       | a    | 5    | const |  1 |  100.00 | NULL |
+----+-------------+--------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
2 rows in set (0.00 sec)

参考文档:

Https://www.cnblogs.com/zhengyun_ustc/p/slowquery1.html
https://www.jianshu.com/p/3989222f7084
https://dev.mysql.com/doc/refman/5.6/en/subquery-optimization.html

到此这篇关于MySQL之select in 子查询优化的实现的文章就介绍到这了,更多相关MySQL select in 子查询优化内容请搜索自学编程网以前的文章或继续浏览下面的相关文章希望大家以后多多支持自学编程网！

您可能感兴趣的文档:

--结束END--

本文标题: MySQL之select in 子查询优化的实现

本文链接: https://lsjlt.com/news/9826.html(转载时请注明来源链接)

有问题或投稿请发送至: 邮箱/279061341@qq.com    QQ/279061341

猜你喜欢
  • MySQL之select in 子查询优化的实现
    下面的演示基于MySQL5.7.27版本 一、关于MySQL子查询的优化策略介绍: 子查询优化策略 对于不同类型的子查询，优化器会选择不同的策略。 对于 IN、=ANY 子查询，优化器有如下策略选择： s...
    99+
    2022-05-13
    MySQL select in 子查询 MySQL select in MySQL 子查询
  • Mysql查询优化之IN子查询优化方法详解
    目录物化表物化表转连接总结物化表 首先提出一个不相关的IN子查询 SELECT * FROM s1 WHERE key1 IN (SELECT commo...
    99+
    2023-02-09
    mysql in子查询优化 mysql in语句优化 mysql查询效率优化
  • MySql子查询IN的执行和优化的实现
    目录IN为什么慢？IN和EXISTS哪个快？如何提高效率？MySQL5.6对子查询的优化？SEMI JOIN策略Duplicate Weedout优化Materialization优...
    99+
    2024-04-02
  • MySql子查询IN的执行和优化的实现方法
    这篇文章主要讲解了“MySql子查询IN的执行和优化的实现方法”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“MySql子查询IN的执行和优化的实现方法”吧！目录IN为什么慢？IN和EXIST...
    99+
    2023-06-20
  • mysql in慢查询优化
    目录记一次mysql慢查询优化——生产环境待办列表现场演示5~6s才加载出来结果；顿时，产品经理的脸挂不住了，作为多年经验的老开发，心想完犊子，脸啪啪滴。 不过，秉着多年的江湖经验，遇事不慌，拍个...
    99+
    2023-05-12
    mysql in慢查询优化 mysql in慢查询优化
  • mysql的in+子查询
    【mysql最糟糕的子查询：in+子查询】 select * from film where film_id in (select film_id from film_actor where acto...
    99+
    2023-08-18
    mysql
  • MySQL SQL优化教程之in和range查询
    首先我们来说下in()这种方式的查询。在《高性能MySQL》里面提及用in这种方式可以有效的替代一定的range查询，提升查询效率，因为在一条索引里面，range字段后面的部分是不生效的。使用in这种方式其实MySQ...
    99+
    2022-05-20
    mysql in查询 mysql优化in mysql优化range查询
  • mysql select后面的子查询
    select后面的子查询使用,只能是标量查询 #案例：查询每个部门的员工个数 SELECT d.*,( SELECT COUNT(*) FROM employees WHE...
    99+
    2024-04-02
  • 数据库查询优化之子查询优化的示例分析
    这篇文章将为大家详细讲解有关数据库查询优化之子查询优化的示例分析，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。1. 案例取所有不为掌门人的员工，按年龄分组！selec&#...
    99+
    2024-04-02
  • mysql in慢查询如何优化
    这篇文章主要介绍“mysql in慢查询如何优化”，在日常操作中，相信很多人在mysql in慢查询如何优化问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”mysql in慢查...
    99+
    2022-12-30
    mysql
  • mysql对子查询的优化改写
    《高性能mysql第三版》提到mysql会将in子查询改写成exists查询（书中基于的mysql版本是5.1.50和5.5） 但是在5.6之后，已经优化成使用半连接查询 首先要提的当然是臭名昭著的MySQL子查询问题，在MySQ...
    99+
    2017-04-10
    mysql对子查询的优化改写
  • mysql in索引慢查询优化实现步骤解析
    目录记一次mysql慢查询优化第一步、分析SQL第二步、检查索引，执行explainwhywhy第三步、检查两个关联字段的字段类型、长度和字符类型是否一致第四步、强制使用索引操作第五...
    99+
    2023-05-20
    mysql in慢查询优化 mysql in索引
  • SQL优化教程之in与range查询
    前言 《高性能MySQL》里面提及用in这种方式可以有效的替代一定的range查询，提升查询效率， 因为在一条索引里面，range字段后面的部分是不生效的（ps.需要考虑 ICP） 。MySQL优化器将in这种方式转...
    99+
    2022-05-13
    sql优化 in mysql in查询 mysql range查询
  • MySQL 查询语句优化的实现
    子查询优化 将子查询改变为表连接，尤其是在子查询的结果集较大的情况下；添加复合索引，其中复合索引的包含的字段应该包括 where 字段与关联字段；复合索引中的字段顺序要遵守最左匹配原则；mysql 8 中自动对...
    99+
    2023-04-20
    MySQL 查询语句优化 MySQL 查询语句
  • 技术分享 | MySQL 子查询优化
    作者：胡呈清 爱可生 DBA 团队成员，擅长故障分析、性能优化，个人博客：https://www.jianshu.com/u/a95ec11f67a8，欢迎讨论。 本文来源：原创投稿 *爱可生开源社区出品，原创内容未经授权不得随意使用，转...
    99+
    2016-07-07
    技术分享 | MySQL 子查询优化
  • MySQL实验 子查询优化双参数limit - G
    MySQL实验 子查询优化双参数limit 没想到双参数limit还有优化的余地，为了亲眼见到，今天来亲自实验一下。   实验准备 使用MySQL官方的大数据库employees进行实验，导入该示例库见此 准备使用其中的emplo...
    99+
    2018-07-05
    MySQL实验 子查询优化双参数limit - G
  • MySQL优化之慢查询日志
    慢查询日志概述 所谓慢查询日志，就是用于记录MySQL中响应时间超过设定阈值的SQL语句，通过打开慢查询开关，MySQL会将大于阈值的SQL记录在日志中，以便于分析性能。 慢查询日志选项默认是关闭的，如果要开启，则需要手动设置。 ...
    99+
    2021-08-28
    MySQL优化之慢查询日志
  • MySQL之join查询优化方式
    目录MySQL join查询优化1. 那什么是驱动表呢？2. 复杂的sql怎么识别驱动表呢？3. 关联查询原理是怎样的？4. 该如如何优化？5. 实例MySQL优化(关联查询优化)准...
    99+
    2023-03-12
    MySQL join查询 join查询优化 MySQL查询优化
  • MySQL之join查询如何优化
    这篇文章主要介绍“MySQL之join查询如何优化”，在日常操作中，相信很多人在MySQL之join查询如何优化问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”MySQL之join查询如何优化”的疑惑有所帮助！...
    99+
    2023-07-05
  • MySQL 大数据in查询该怎么优化
    对于 MySQL 中的大数据 IN 查询，可以使用以下方法进行优化： 尽可能使用索引。如果使用 IN 操作符的字段有索引，MySQL 将会使用索引来加速查询。 尽量使用常量作为 IN 操作符中的参数，而不是使用子查询或者表达式。因为 M...
    99+
    2023-09-16
    mysql 大数据 数据库
软考高级职称资格查询
热门wiki
近期文章
推荐阅读
热门问答
热门标签
编程网，编程工程师的家园，是目前国内优秀的开源技术社区之一，形成了由开源软件库、代码分享、资讯、协作翻译、讨论区和博客等几大频道内容，为IT开发者提供了一个发现、使用、并交流开源技术的平台。

  • 官方手机版

  • 微信公众号

  • 商务合作