MySQL 优化 基于规则优化

已于 2022-02-12 17:15:57 修改 335 收藏 2
文章标签： mysql sql 数据库
于 2022-02-10 20:26:50 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_46369347/article/details/122868647
版权

MySQL知识总结

《MySQL是怎样运行的》知识总结

单表访问方法

表的连接原理

优化 基于查询成本的优化

优化需要的统计数据

优化 基于规则的优化

Explain详解

InnoDB缓冲区

事务

redo日志

undo 日志

MVCC原理

MySQL 锁

14 基于规则的优化

​ MySQL会基于一些规则重写我们写的语句，使得查询的执行更加高效

表的结构

# 表single_table
CREATE TABLE single_table (
    id           int not null auto_increment,
    key1         VARCHAR(100),
    key2         int,
    key3         varchar(100),
    key_part1    varchar(100),
    key_part2    varchar(100),
    key_part3    varchar(100),
    common_field varchar(100),
    primary key (id),
    key idx_key1 (key1),
    unique key uk_key2 (key2),
    key idx_key3 (key3),
    key idx_part (key_part1, key_part2, key_part3)
) ENGINE = INNODB
  CHARSET = utf8;

# 表t1
create table t1
(
    m1 int,
    n1 char(1)
);

# 表t2
create table t2
(
    m2 int,
    n2 char(1)
);

insert into t1
values (1, 'a'),
       (2, 'b'),
       (3, 'c');

insert into t2
values (2, 'b'),
       (3, 'c'),
       (4, 'd');

条件化简

​ 我们编写的查询语的搜索条件本质上是条件表达式，这些表达式可能比较复杂，不能高效地执行查询，MySQL优化器会为我们化简这些表达式。

移除不必要的括号

select *
from t1,
     (t2, t3);# 移除不必要的括号

select *
from t1,
     t2,
     t3;

常量传递

​ 某个表达式是某个列与常量的等值匹配

select *
from single_table
where key1 = 'a'
  and key3 > key1;

select *
from single_table
where key1 = 'a'
  and key3 > 'a';# 常量传递

移除没有用的条件

​ 移除明显永远为true、false的表达式

select *
from single_table
where key1 = 'a'
  and 1 = 1;# 移除没有用的条件

select *
from single_table
where key1 = 'a';

表达式计算

​ 表达式包含常量时，它的值会优先计算出来

select *
from single_table
where key2 > 8880 + 8;

select *
from single_table
where key2 > 8888;# 计算表达式

having与where子句的合并

​ 查询语句没有出现聚集函数、group by子句，查询优化器就会把having、where子句进行合并

常量表检测

​ 以下情况的两种类型的查询速度非常快

  1. 查询的表没有或只有一条记录
  2. 使用主键等值匹配或唯一索引等值匹配作为查询条件来查询某个表

这两种方式查询的表被成为常量表，优化器在分析一个查询语句时，会首先执行常量表查询，在得到查询结果后，把查询涉及常量表的条件都替换掉

select *
from s1
         join s2 on s1.key2 = s2.key2
where s1.key2 = 8180; 

#执行常量表查询后，只有一条记录
select s1.*,s2.*
from s1
         join s2 on s1.key2的常量值 = s2.key2;

外连接消除

​ 我们知道外连接的驱动表中，如果不能在被驱动表找到on子句匹配的记录，也会将驱动表记录加入到结果集，而对于不符合where子句查询条件的记录不会参与连接，因此如果我们设置了查询条件被驱动表的列不为NULL，那么此时的外连接就跟内连接一样了

select *
from t1
         left join t2 on t1.m1 = t2.m2
where t2.m2 is not null;

+------+------+------+------+
| m1   | n1   | m2   | n2   |
+------+------+------+------+
|    2 | b    |    2 | b    |
|    3 | c    |    3 | c    |
+------+------+------+------+

​ 只要有隐含被驱动表的列不为NULL的条件，就会出现上述情况

​ 空值拒绝：在外连接查询中，指定的where子句包含被驱动表中的列不为null值的条件，在被驱动表的where子句符合空值拒绝的条件后，外连接与内连接就可以相互转换，这种转换带来了好处，优化器可以评估不同表的连接顺序的成本，选择成本较低的那种连接顺序进行查询。

子查询优化

​ 在一个查询语句中的某个位置可以有另一个查询语句，这个查询就是子查询

​ 出现在select子句中：

select (select key2 from single_table limit 1);

​

​ 出现在from子句中：把子查询的查询结果当作一个表，子查询后面，为这个表设置了别名t，MySQL把这种放在from子句后面的表称为派生表。

select k2
from (select key1, key2 k2, key3
      from single_table) t;

子查询分类

按返回的结果集区分

  1. 标量子查询：只返回单一值，标量子查询可以作为一个值或表达式的一部分
  2. 行子查询：返回一条记录（记录只有一列，就是标量子查询）
  3. 列子查询：返回一个列的数据（只有一条记录，就是标量子查询）
  4. 表子查询：返回多行、多列的数据

按与外层查询的关系

  • 不相关子查询：子查询可以单独运行出结果，不依赖于外层子查询
select *
from t1
where n1 in (select n2 from t2);
  • 相关子查询：子查询的执行依赖于外层查询
select *
from t1
where n1 in (select n2 from t2 where m1 = m2);# m1 = m2条件中需要用到外层查询的列

子查询在布尔表达式中的使用

​ 我们平时使用子查询最多的地方就是把它作为布尔表达式一部分，用在where子句或on子句中查询条件中，布尔表达式形式是：

  • 操作数 操作符 (子查询)

操作符为比较运算符（=、>、<、>=、<=、!=、<=>）

这里的操作数可以是某个列名、常量、更为复杂的表达式、子查询

布尔表达式中的子查询需要为标量子查询或行子查询

select *
from t1
where m1 < (select m2 from t2 where n2 = 'd');# 子查询为标量子查询

select *
from t1
where (n1, m1) in (select n2, m2 from t2);# 子查询可以认为是行子查询、表子查询
  • [not] in、any、all子查询

​ 对于列子查询、表子查询，它们的结果集中有多条记录，这些记录相当于一个集合，所有不能单纯的使用 操作数 操作符 (子查询)组成的布尔值表达式了。

select *
from t1
where (n1, m1) in (select n2, m2 from t2);# 子查询可以认为是行子查询、表子查询

in子句的布尔表达式表示某个操作数是否存在于一个集合中

select *
from t1
where n1 < any (select n2 from t2);

# 与上面语句等价
select *
from t1
where n1 < (select max(n2) from t2);

any子句构成的布尔表达式意思是，只要在子查询结果集中存在一个值，某个指定的操作数与该值通过
操作符得到的结果为true，那么表达式的结果就为true。

all子句构成的布尔表达式，则要求某个操作数与子查询结果集中的所有值通过操作符得到结果都为true，那么布尔表达式的结果才为true。

  • exists子查询

我们仅仅判断子查询的结果集中是否有记录，而不关心记录具体是什么，那么可以使用exists子句

select *
from t1
where exists(select 1 from t2);

只要exists子句子查询的结果集中有记录，exists表达式就为true

注意事项

  1. 子查询必须使用括号
  2. select子句的子查询只能是标量子查询
  3. 要获得标量子查询或行子查询，但不能保证查询的结果为1条，那么就应该使用limit 1
  4. in、any、all子查询不允许有limit语句
  5. 在子查询中使用order by、distinct、没有聚集函数的having子句的group by语句是毫无意义的（子查询的结果是一个集合），集合是否排序、去重并不重要，对于这些无用的语句，优化器一开始就进行了优化
  6. 不允许在增删改某个表时，同时对它进行子查询

子查询的执行

标量子查询与行子查询的执行过程

explain
select *
from single_table s1
where key1 = (select common_field from single_table s2 where s2.key3 = 'a' limit 1);

执行过程如下：

  1. 单独执行子查询
  2. 将子查询的结果当成外层查询的参数，执行外层查询

相关的标量子查询与行子查询的执行过程

select *
from single_table s1
where key1 = (select common_field from single_table s2 where s2.key3 = s1.key3 limit 1);
  1. 先从外层查询中获取一条记录
  2. 从这个记录中找出与子查询相关的值，再执行子查询
  3. 根据子查询的结果与外层查询的查询条件进行判断，如果成立，就将这条记录加入到结果集，否则丢弃
  4. 返回步骤1，直到外层查询没有记录

In子查询优化

select *
from single_table s1
where key1 in (select common_field from single_table s2 where key3 = 'a');
物化表的提出

​ 不相关In子查询的执行过程并不简单，如果子查询的结果太多，内存可能存放不下。

对于表达式 in这种in子句来说，in子句的若干个参数首先会被排序，如果执行查询时不能利用到索引将in子句划分为若干个扫描区间，那么就会对已排好序的参数进行二分查找，加快计算in表达式的效率。

​

​ 于是MySQL不直接将不相关子查询的结果集当作外层查询in子句的参数，而是将结果集存放到一个临时表，但需要注意的是临时表的列是子查询结果集中的列，写入临时表的记录会被去重。

进行去重可以使得临时表的大小变得更小，去重的方式是为相关的列建立主键索引、唯一索引。

一般情况下，子查询的结果集的大小不会很大，为它创建的临时表是基于内存使用的Memory存储引擎创建的，而且还为临时表建立哈希索引。

In子句是判断某个操作数是否在集合中，使用哈希索引可以让匹配的过程非常快。

子查询的结果集非常大，超过了系统变量temp_table_size或max_heap_table_size的值，临时表就会使用基于磁盘存储引擎来保存结果集中的记录，索引的类型也转换为B+树索引。

  • 物化：将子查询的结果集的记录存放到临时表中的过程，物化表中有索引（哈希索引或B+树索引），所以判断某个操作数是否在子查询的结果集中的速度非常快
物化表转连接
select *
from single_table s1
where key1 in (select common_field from single_table s2 where key3 = 'a');

​ 子查询物化后，对于这次的查询就有2个角度来看待

  • 从表s1的角度，查询的意思就是，对于s1表的每一条记录，如果该记录的key1在物化表中，那么记录就会被加入到结果集
  • 从物化表的角度，查询的意思是对于物化表的每个值，如果能在s1表的记录中的key1中找到相等的值，就把这个记录加入到结果集

查询的过程就相当于2表的内连接，优化器可以评估不同连接顺序的查询成本，选择成本较低的连接顺序进行查询

将子查询转换为半连接

​ 能否将子查询直接转换为连接？

select *
from single_table s1
where key1 in (select common_field from single_table s2 where key3 = 'a');

对于这个查询语句，可以理解为，对于s1表中的每一条记录，如果能在s2表（满足条件key3 = 'a'）中的记录中找到一条或多条记录满足key1 = common_field条件，那就把这条记录加入到结果集

  • 上面的语句和下方的语句很像
select s1.*
from single_table s1
         join single_table s2 on s1.key1 = s2.common_field
where s2.key3 = 'a';

对于s1.key1 = s2.common_field条件有3种情况

  1. s1表的某一条记录不能在s2表中找到满足该条件的记录
  2. s1表的某一条记录能在s2表中找到满足该条件的记录1条
  3. s1表的某一条记录能在s2表中找到满足该条件的记录多条，这个记录会被多次添加到结果集中
实现半连接
1. 子查询表上拉（Table Pullout）
select *
from single_table s1
where key2 in (select key2 from single_table s2 where key3 = 'a');

select s1.*
from single_table s1
         join single_table s2 on s1.key2 = s2.key2
where s2.key3 = 'a';

子查询的查询列表只有主键或唯一索引时可以将子查询表上拉到外层查询from子句中

子查询中查询列表为主键索引、唯一索引时，这些列本身就是不重复的，对于s1中同一条记录能在s2中找到满足in子句条件的记录只有一条

2. 重复消除（Duplicate Weedout）
select *
from single_table s1
where key1 in (select common_field from single_table s2 where key3 = 'a');

# 临时表
create table temp (
    id int primary key
);

s1表的某条记录可能在s2表中有多条匹配记录，该记录会被多次添加到结果集中，为了消除重复，可以建立一个临时表，当某条s1的记录满足in语句条件时，就把这条记录的Id加入这个临时表，如果添加成功，说明这条件记录先前没有被加入到最终的结果集，反之，该记录已经被添加到最终结果集，记录将被丢弃。

3. 松散扫描（LooseScan）
select *
from single_table s1
where key3 in (select key1 from single_table s2 where key1 > 'a' and key1 < 'b');

子查询中，对于s2表的访问可以用到key1的列的索引，而子查询的查询列表恰好就是索引列，在将这个查询语句转换为半连接时，执行的过程是扫描s2表中的索引列，索引列的值在s1表中能找到满足in语句条件的记录，就将记录加入到最终的结果集。

虽然是扫描索引，但它只会取索引值相同的第一条记录（对于普通索引，可能有多条相同值的索引记录）去执行匹配操作。

4. 半连接物化（Semi-Materialization）

前文中，把外层查询的in子句的不相关子查询进行物化，然后将外层查询表与物化表进行连接，物化表没有重复的记录，可以将子查询转换为连接查询

5. 首次匹配（FirstMatch）
select *
from single_table s1
where key1 in (select common_field from single_table s2 where s1.key3 = s2.key3);

# 与半连接的方式很像
select s1.*
from single_table s1
         join single_table s2 on s1.key3 = s2.key3
    and s1.key1 = s2.common_field;

原始的半连接的执行方式，过程是：

  1. 取外层查询中的记录，然后到子查询的表中找符合匹配条件的记录
  2. 如果能找到相关的记录，就把外层查询的记录加入到最终结果集并停止该条记录的匹配
  3. 如果找不到符合条件的记录，就把该记录丢弃
  4. 开始下一条外层查询的记录匹配，知道外层查询没有记录为止
半连接适用的条件
  • 查询语句的形式如下的：
select XXX
from outer_tables
where expr in (select XXX inner_tables XXX)
  and XXX;

select XXX
from outer_tables
where (oe1, oe2) in (select ie1, ie2, XXX inner_tables XXX)
  and XXX;

  • 适用的情况：

    • 子查询必须与in子句组成布尔表达式，并且在外层查询的where、on子句出现
    • 外层查询可有其他查询条件，但必须使用and操作符、in子查询的查询条件连接起来
    • 子查询必须是一个单一的查询，不能是union连接起来的若个查询
    • 子查询不能包含group by、having语句或聚集函数

  • 不适用的情况：

    • 外层查询的where子句，存在其他查询条件使用or操作符与in子查询组成布尔表达式连接
    • 使用not in，而非in
    • 位于select子句的in子查询
    • 子查询包含group by、having或聚集函数
    • 子查询包含了union

  • 对于不能转换为半连接的查询的子查询，MySQL仍然对其进行了优化

    • 对于不相关子查询，可以把它们物化后再参与查询，加快查询执行的速度

    将子查询物化后不能转换为与外层查询表的连接，只能是先扫描外层查询的表的记录，针对这一记录来判断该记录相关的值能否再物化表中查询到

    ​

    • 无论子查询是相关还是不相关，都可以将in子查询尝试转换为exists子查询，只要in子查询放在where或on子句中，那么in和exists的转换就没问题，进行转换可能才会用到索引
    select *
from single_table s1
where key1 in (select key3 from single_table s2 where s1.common_field = s2.common_field)
   or key2 > 1000;

    select *
from single_table s1
where exists(select 1 from single_table s2 where s1.common_field = s2.common_field and s1.key1 = s2.key3)
   or key2 > 1000;

    转换为exists子查询后，便可以使用s2表的key3的索引

    如果in子查询不满足半连接的条件，又不能转换为物化表或转换成本太高，那么它就会转换为exists子查询

总结
  • 如果in子查询满足转换为半连接的条件，优化器会优先把子查询转换为半连接，然后在考虑从下面5种执行半连接策略中选择成本较低的执行策略来执行子查询
    • 子查询表上拉
    • 重复值消除
    • 松散扫描
    • 半连接物化
    • 首次匹配
  • 如果in子查询不满足半连接的条件，那么就会执行下面的策略选择成本较低来执行子查询
    • 将子查询物化，再执行查询
    • 将in子查询转换为exists子查询

Any与All子查询优化

如果any、all子查询是不相关子查询，它们再很多场合都能转换我们熟悉的方式执行

  • < any (select inner_expr XXX)和< (select max(inner_expr) XXX)
  • < all (select inner_expr XXX)和< (select min(inner_expr) XXX)

[not] exists子查询优化

​ 如果exists子查询是不相关子查询，就可以先执行子查询，得出[not] exists子查询的结果，再重写原先的查询语句。

select *
from single_table
where exists(select 1 from single_table s2 where key1 = 'a')
   or key2 > 100;

# 重写
select *
from single_table
where true
   or key2 > 100;

# 进一步重写
select *
from single_table
where true;

如果exist子查询的结果为true，那么优化器就会重写查询

如果exist子查询是相关子查询，那么就只能进行外层查询后，再拿结果与子查询进行匹配，不断重复步骤的方式来执行查询

对派生表的优化

​ 把子查询放在from语句后面，这个子查询的结果就相当于一个派生表

select *
from (select key1 k1, key2 k2, key3 k3 from single_table where key1 = 'a') t
where k3 = 'a';

对于派生表的查询，MySQL提供了2种执行策略

​ 将派生表物化，MySQL使用了延迟物化的策略，只有再查询真正使用到派生表时才尝试物化派生表，而不是在执行查询前就物化派生表

select *
from (select * from single_table s1 where key1 = 'a') t
         join single_table s2 on t.key1 = s2.key1
where s2.key2 = -1;

如果采用物化表的方式执行上述查询语句，在执行时首先会到s2表找出满足s2.key2 = -1的记录，如果找不到符合条件的记录，也就没有必要将派生表物化

​ 将派生表和外层查询合并（重写为没有派生表的形式）

select *
from single_table s1
         join single_table s2 on s1.key1 = s2.key1
where s1.key1 = 'a'
  and s2.key2 = -1;

与上方的查询语句一样

通过将外层查询和派生表合并的方式能成功消除派生表，不用再付出成本去创建、访问临时表

有些带派生表的查询不能与外层查询合并，比如包含了一下函数或语句的查询：

  1. 聚集函数
  2. distinct
  3. group by
  4. having
  5. limit
  6. union
  7. union all
  8. 派生表的子查询的select子句包含了子查询

MySQL再执行有派生表的查询时，优先尝试将派生表与外层查询合并，如果不行，则把派生表物化，再查询

011eH
关注
  • 0
    点赞
  • 踩
  • 2
    收藏
  • 打赏
    打赏
  • 0
    评论
漫谈分布式系统(20) -- 基于规则的优化
漫谈大数据
07-08 355
这是《漫谈分布式系统》系列的第 20 篇，预计会写 30 篇左右。每篇文末有为懒人准备的 TL;DR，还有给勤奋者的关联阅读。扫描文末二维码，关注公众号，听我娓娓道来。也欢迎转发朋友圈分...
17-Explain执行计划-01
最新发布
Victor_An的博客
11-16 293
有了慢查询语句后，就要对语句进行分析。一条查询语句在经过 MySQL 查询优化器的各种基于成本和规则的优化会后生成一个所谓的执行计划，这个执行计划展示了接下来具体执行查询的方式，比如多表连接的顺序是什么，对于每个表采用什么访问方法来具体执行查询等等。EXPLAIN 语句来帮助我们查看某个查询语句的具体执行计划，我们需要搞懂EPLATNEXPLAIN 的各个输出项都是干嘛使的，从而可以有针对性的提升我们查询语句的性能。
【Oracle】看懂执行计划之基于规则的优化器（RBO）
As before 如初
04-16 308
简介   基于规则的优化器（RBO）是通过编码在Oracle数据库中的一系列固定的规则，来决定目标SQL的执行计划。Oracle事先给各种类型的执行路径定一个等级，从1到15，等级1对应执行路径的执行效率最高，等级15对应执行路径的执行效率最低。对于等级相同的执行计划，oracle根据目标对象在数据字典中缓存的顺序判断选择哪一种执行计划。在决定目标SQL的执行计划时，RBO会从该SQL的诸多执行路径中选择一条等级最低的执行路径来作为其执行计划。   RBO中等级1对应的执行路径是“single row by
Mysql工作原理——基于规则的优化
mashaokang1314的博客
12-03 192
Mysql依据一些规则将很糟糕的语句转换成某种可以比较高效执行的形式，这个过程被称为查询重写。 条件化简 移除不必要的括号 ((a = 5 AND b = c) OR ((a > c) AND (c < 5))) #化简后 (a = 5 and b = c) OR (a > c AND c < 5) 常量传递（constant_propagation） a=5 and b>a; #花间后 a=5 and b>5; 等值传递（equality_propagat
mysql 基于规则的执行计划(二)
cqhiabc50405的博客
12-04 52
上篇文章说mysql还在用基于规则的优化器，是我的误解，里面涉及到Covering Index，获取数据的方式，Cost的计算等等，总之，刚从oracle来搞mysql，两者差别还是挺大的： The STRAIGHT_J...
【MySQL学习笔记（十二）】之 查询优化器基于规则的优化与子查询优化
开发小鸽
02-17 164
本文章由公号【开发小鸽】发布！欢迎关注！！！ 老规矩–妹妹镇楼： 一． 查询优化器基于规则的优化 （一） 概述        查询优化器针对查询语句根据相应的规则进行优化，转换为某种可以高效执行的形式，这个过程称为查询重写。 （二） 条件化简 1. 移除不必要的括号        将表达式中多余的括号去掉。 2. 常量传递        若某个列和某个常量已经进
mysql优化器基于成本_sql优化器基于规则优化器和基于成本优化器的区别
weixin_42486913的博客
02-08 325
sql优化器基于规则优化器和基于成本优化器的区别Oracle有两种优化器：RBO和CBO。 RBO的最大的问题在于靠硬编码在ORACLE数据库代码中的一系列规定的规则来决定目标SQL的执行计划的，而并没有考虑目标SQL中所涉及的对象的时间数据量，实际数据分布情况，这样一旦规定规则并不适用于该SQL中所涉及的实际对象时，RBO根据规定规则产生的执行计划就很可能不是当前情况下的最优执行计划了。下面我们...
《MySQL是怎么样运行的》读书笔记四--基于成本的优化
codepupil的博客
02-15 1041
基于成本的优化 MySQL中一条查询语句的执行成本是由下边这两个方面组成的： 查询成本=I/O成本+CPU成本 I/O成本：从磁盘到内存这个加载的过程损耗的时间称之为I/O成本。 CPU成本：读取以及检测记录是否满足对应的搜索条件、对结果集进行排序等这些操作损耗的时间称之为CPU成本。 成本常数：一个页面花费的成本默认是1.0，读取以及检测一条记录是否符合搜索条件的成本默认是0.2。1.0、0.2这些数字称之为成本常数。 基于成本的优化步骤： 根据搜索条件，找出所有可能使用的索引（找出
mysql 基于规则的执行计划
cqhiabc50405的博客
12-03 98
oracle 里有基于规则的执行计划，不过现在很少用了。mysql里也有这种，不过看起来很弱智，还是我的错觉，明天继续： mysql> set profiling=1;Query OK, 0 rows affect...
谁最便宜就选谁 —— MySQL 基于成本的优化
qq_35474709的博客
10-19 104
基于成本的优化 标签： MySQL 是怎样运行的 什么是成本 我们之前老说MySQL执行一个查询可以有不同的执行方案，它会选择其中成本最低，或者说代价最低的那种方案去真正的执行查询。不过我们之前对成本的描述是非常模糊的，其实在MySQL中一条查询语句的执行成本是由下边这两个方面组成的： I/O成本 我们的表经常使用的MyISAM、InnoDB存储引擎都是将数据和索引都存储到磁盘上的，当我们想查询表中的记录时，需要先把数据或者索引加载到内存中然后再操作。这个从磁盘到内存这个加载的过程损耗的时间
mysql优化器RBO_RBO基于规则的优化器access paths优先级
weixin_39927214的博客
02-08 101
RBO基于规则的优化器access paths优先级:RBO Path 1: Single Row by RowidRBO Path 2: Single Row by Cluster JoinRBO Path 3: Single Row by Hash Cluster Key with Unique or Primary KeyRBO Path 4: Single Row by Unique or...
基于规则的优化
weixin_43213064的博客
03-14 3647
MySQL会对用户编写的查询语句重写一些重写操作，比如： 移除不必要的括号 常两传递 移除没用的条件 表达式计算 HAVING子句和WHERE子句的合并。 常量表的检测 在被驱动表的WHERE子句符合空值拒绝的条件时，外连接和内连接可以相互转换，子查询可以按照不同的维度进行不同的分类，比如按照子句查询返回的结果分类： 标量子查询 行子查询 列子查询 表子查询 按照与外层查询的关系分类： 不想关子查询 相关子查询 IN子查询有很多优化，如果IN子查询符合转换为半连接的条件，查询优化器会优先把该子查
Hive 基于规则的优化和基于代价的优化
houzhizhen的专栏
03-24 2909
本文假定读者对执行计算，普通 join 执行，Map join，Bucket Map join，SMB((Sort Merge Bucket) join， Skew Join 比较熟系。 背景知识 Hive 执行计划解释示例 Hive Bucket Table 的功能和使用方法详解 Hive 使用 List Bucketing 表解决数据倾斜问题 基于规则的优化 基于规则的优化（Rule Based Optimization）:预先定义一些规则，按这些规则进行优化，效率更高。 不同的 SQL 处理器根据不同
我必须得告诉大家的MySQL优化原理2
心向阳光
06-03 298
原文链接：https://www.jianshu.com/p/01b9f028d9c7來源：简书如果有同学看完上一篇关于MySQL文章，文末留有两个很开放的问题，如有兴趣可以在脑袋里想想。本文也会试着回答这两个问题，希望能给你一些参考。现在可以思考一个问题，如果数据量非常大的情况下，您根据业务选择了合适的字段，精心设计了表和索引，还仔细的检查了所有的SQL，并确认已经没什么问题，但性能仍然不能满足...
基于规则的优化器
天行健君子以自强不息
01-12 918
1、优化器是oracle数据库中内置的一个核心子系统，也可以把它理解成是oracle数据库中的一个核心的模块或者一个核心功能组件， 优化器的目的是为了得到目标sql的执行计划 2、oracle数据库里的优化器又分为RBO和CBO这两种类型。 3、RBO所用的判断原则为一组内置的规则，这些规则是硬编码在oracle数据库的代码中的，RBO会根据这些规则从目标sql诸多可能的执行
MySQL 数据库创建/优化规则
php菜鸟技术天地
10-10 355
(一)建表规约 1. 【强制】表达是与否概念的字段，必须使用 is_xxx 的方式命名，数据类型是 unsigned tinyint （1 表示是，0 表示否）。 说明：任何字段如果为非负数，必须是 unsigned。 注意：POJO 类中的任何布尔类型的变量，都不要加 is 前缀，所以，需要在<resultMap>设置 从 is_xxx 到 Xxx 的映射关系。数据库表示是与否的值，使用 tinyint 类型，坚持 is_xxx 的 命名方式是为了明确其取值含义与取值范围
CBO（基于规则的优化方式）模式下优化器模式的选择
谢辉的专栏
07-04 1081
对于一种功能单一的数据库系统来讲，设置一个数据库优化器模式就可以了，比如olap系统，绝大多数上运行的是报表作业 执行的大多是sql的聚合类函数   比如group by 函数，这时候优化器模式设置成all_rows模式就可以了，但是如果此数据库上 还运行着一些用户查询功能，比如查询功能是分页的，如果优化器模式设置成all_rows模式  就会导致查询功能非常的慢 针对这种情况   我们可以
MySQL：MySQL是如何通过各种规则去优化执行计划的
OceanStar的博客
12-26 118
MySQL在生成具体执行计划的时候，会根据成本计算去选择最优的执行计划，因为每个查询执行的时候实际都可能有多种执行计划可以选择，必须要选择成本最低的那种 MySQL在执行一些相对较为复杂的SQL语句的时候会对查询进行重写来优化具体的执行计划，因为它有可能可能会觉得你的SQL写的一点都不好，直接按你的SQL生成的执行计划效率不够高，需要自动帮你改改 常量替换 首先，要是MySQL觉得你的SQL里有很多括号，那么无关紧要的括号它会给你删除了。 其次，比如你有类似于i = 5 and j > i这样的SQ

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题：创作都市 设计师：CSDN官方博客 返回首页
评论

打赏作者

011eH

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额：-- )
扫码支付
扫码支付：¥2
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、C币套餐、付费专栏及课程。

余额充值