ToprowDB Dynamic Server 查询优化技术---子查询优化--02-2

最新推荐文章于 2025-02-17 15:12:28 发布
原创 最新推荐文章于 2025-02-17 15:12:28 发布 · 565 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文通过具体SQL语句对比分析了ToprowDB、PostgreSQL与MySQL三种数据库的查询优化能力，特别是针对EXISTS类型的子查询，展示了不同数据库在优化策略上的差异。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >


1.1.1 PostgreSQL

1.1.2.1  S1语句

查看查询执行计划，子查询被优化（采用半连接）。

postgres=# EXPLAIN SELECT * FROM t3 WHERE EXISTS (SELECT b1 FROM t1 WHERE a3=a1);

                            QUERY PLAN

------------------------------------------------------------------

 Hash Semi Join  (cost=55.90..114.35 rows=2040 width=12)

   Hash Cond: (t3.a3 = t1.a1)

   ->  Seq Scan on t3  (cost=0.00..30.40 rows=2040 width=12)

   ->  Hash  (cost=30.40..30.40 rows=2040 width=4)

         ->  Seq Scan on t1  (cost=0.00..30.40 rows=2040 width=4)

(5 行记录)

1.1.2.2  S2语句

查看查询执行计划，子查询被优化（采用半连接）。

postgres=# EXPLAIN SELECT * FROM t3 WHERE EXISTS (SELECT a1 FROM t1 WHERE a3=a1);

                            QUERY PLAN

------------------------------------------------------------------

 Hash Semi Join  (cost=55.90..114.35 rows=2040 width=12)

   Hash Cond: (t3.a3 = t1.a1)

   ->  Seq Scan on t3  (cost=0.00..30.40 rows=2040 width=12)

   ->  Hash  (cost=30.40..30.40 rows=2040 width=4)

         ->  Seq Scan on t1  (cost=0.00..30.40 rows=2040 width=4)

(5 行记录)

1.1.2.3  S3语句

查看查询执行计划，子查询被优化（采用半连接）。

postgres=# EXPLAIN SELECT * FROM t3 WHERE EXISTS (SELECT id1 FROM t1 WHERE a3=a1)

                            QUERY PLAN

------------------------------------------------------------------

 Hash Semi Join  (cost=55.90..114.35 rows=2040 width=12)

   Hash Cond: (t3.a3 = t1.a1)

   ->  Seq Scan on t3  (cost=0.00..30.40 rows=2040 width=12)

   ->  Hash  (cost=30.40..30.40 rows=2040 width=4)

         ->  Seq Scan on t1  (cost=0.00..30.40 rows=2040 width=4)

(5 行记录)

1.1.2.4  S4语句

查看查询执行计划，子查询被优化。

postgres=# EXPLAIN SELECT * FROM t3 WHERE EXISTS (SELECT b1 FROM t1 WHERE a1>2);

                         QUERY PLAN

-------------------------------------------------------------

 Result  (cost=0.05..30.45 rows=2040 width=12)

   One-Time Filter: $0

   InitPlan 1 (returns $0) //子查询被优化，只被执行一次，类似其他数据库如MySQL对子查询的物化优化

     ->  Seq Scan on t1  (cost=0.00..35.50 rows=680 width=0)

           Filter: (a1 > 2)

   ->  Seq Scan on t3  (cost=0.00..30.40 rows=2040 width=12)

(6 行记录)

1.1.2.5  S5语句

查看查询执行计划，子查询被优化。

postgres=# EXPLAIN SELECT * FROM t3 WHERE EXISTS (SELECT a1 FROM t1 WHERE b3=b1);

                               QUERY PLAN

------------------------------------------------------------------------

 Hash Join  (cost=40.00..98.45 rows=1020 width=12)

   Hash Cond: (t3.b3 = t1.b1)

   ->  Seq Scan on t3  (cost=0.00..30.40 rows=2040 width=12)

   ->  Hash  (cost=37.50..37.50 rows=200 width=4)

         ->  HashAggregate  (cost=35.50..37.50 rows=200 width=4)  //在t1表上执行了一个hash聚集操作

               Group Key: t1.b1

               ->  Seq Scan on t1  (cost=0.00..30.40 rows=2040 width=4)

(7 行记录)  

1.1.2 MySQL

1.1.3.1  S1语句

查看查询执行计划，子查询没有被优化。

mysql> EXPLAIN SELECT * FROM t3 WHERE EXISTS (SELECT b1 FROM t1 WHERE a3=a1);

+----+--------------------+-------+------+------+-------------+

| id | select_type        | table | type | key  | Extra       |

+----+--------------------+-------+------+------+-------------+

|  1 | PRIMARY            | t3    | ALL  | NULL | Using where |

|  2 | DEPENDENT SUBQUERY | t1    | ref  | a1   | NULL        |

+----+--------------------+-------+------+------+-------------+

2 rows in set (0.02 sec)

1.1.3.2  S2语句

查看查询执行计划，子查询没有被优化。

mysql> EXPLAIN SELECT * FROM t3 WHERE EXISTS (SELECT a1 FROM t1 WHERE a3=a1);

+----+--------------------+-------+------+------+-------------+

| id | select_type        | table | type | key  | Extra       |

+----+--------------------+-------+------+------+-------------+

|  1 | PRIMARY            | t3    | ALL  | NULL | Using where |

|  2 | DEPENDENT SUBQUERY | t1    | ref  | a1   | Using index |

+----+--------------------+-------+------+------+-------------+

2 rows in set (0.00 sec)

1.1.3.3  S3语句

查看查询执行计划，子查询没有被优化。

mysql> EXPLAIN SELECT * FROM t3 WHERE EXISTS (SELECT id1 FROM t1 WHERE a3=a1);

+----+--------------------+-------+------+------+-------------+

| id | select_type        | table | type | key  | Extra       |

+----+--------------------+-------+------+------+-------------+

|  1 | PRIMARY            | t3    | ALL  | NULL | Using where |

|  2 | DEPENDENT SUBQUERY | t1    | ref  | a1   | Using index |

+----+--------------------+-------+------+------+-------------+

2 rows in set (0.00 sec)

1.1.3.4  S4语句

查看查询执行计划，子查询没有被优化。

mysql> EXPLAIN SELECT * FROM t3 WHERE EXISTS (SELECT b1 FROM t1 WHERE a1>2);

+----+-------------+-------+-------+------+-----------------------+

| id | select_type | table | type  | key  | Extra                 |

+----+-------------+-------+-------+------+-----------------------+

|  1 | PRIMARY     | t3    | ALL   | NULL | NULL                  |

|  2 | SUBQUERY    | t1    | range | a1   | Using index condition |

+----+-------------+-------+-------+------+-----------------------+

2 rows in set (0.01 sec)

1.1.3.5  S5语句

查看查询执行计划，子查询没有被优化。

mysql> EXPLAIN SELECT * FROM t3 WHERE EXISTS (SELECT a1 FROM t1 WHERE b3=b1);

+----+--------------------+-------+------+------+-------------+

| id | select_type        | table | type | key  | Extra       |

+----+--------------------+-------+------+------+-------------+

|  1 | PRIMARY            | t3    | ALL  | NULL | Using where |

|  2 | DEPENDENT SUBQUERY | t1    | ALL  | NULL | Using where |

+----+--------------------+-------+------+------+-------------+

2 rows in set (0.00 sec)

1.1.4 对比

我们把原始的SQL语句复制一份，目的是查阅方便。

 

S1: SELECT * FROM t3 WHERE b3 EXISTS (SELECT b1 FROM t1 WHERE a3=a1);

S2: SELECT * FROM t3 WHERE b3 EXISTS (SELECT a1 FROM t1 WHERE a3=a1);

S3: SELECT * FROM t3 WHERE b3 EXISTS (SELECT id1 FROM t1 WHERE a3=a1);

S4: SELECT * FROM t3 WHERE id3 EXISTS (SELECT b1 FROM t1 WHERE a1>2);

S5: SELECT * FROM t3 WHERE EXISTS (SELECT a1 FROM t1 WHERE b3=b1);

 

然后对比如下:

SQL语句

语句特点

ToprowDB

PostgreSQL

MySQL

S1

相关子查询，目标列为普通列，条件为索引键

Join优化

Semi Join优化

没有被优化

S2

相关子查询，目标列为唯一键，条件为索引键

Join优化

Semi Join优化

没有被优化

S3

相关子查询，目标列为主键列，条件为索引键

Join优化

Semi Join优化

没有被优化

S4

非相关子查询，目标列为普通列，条件为索引键

没有被优化

类似物化优化

没有被优化

S5

相关子查询，目标列为唯一键，条件为普通列

Semi Join优化

Join优化

没有被优化

分析：

q  从整体上看，对于EXISTS类型的子查询，PostgreSQL的优化能力最强，MySQL最差，ToprowDB接近PostgreSQL

q  对于EXISTS类型的子查询，PostgreSQL基本上是利用Semi Join来进行优化的；多数数据库的优化器都会有类似的方式来对EXISTS类型的子查询进行优化

q  但对于ToprowDB却采取的是普通Join，这是为什么？其实，ToprowDB的优化器也是先进行了Semi Join式优化，然后根据唯一性（唯一索引如S1中的a3=a1）进一步判断，在明知不会产生重复元组的情况下，把Semi Join进一步优化为Join。这点体现了ToprowDB优化器的先进性

q  对比S1和S5（关键在于WHERE条件选元组），PostgreSQL把S5优化为Join操作，这在PostgreSQL中属于特例，PostgreSQL在经过逻辑优化（转为Semi Join属于逻辑优化）之后，利用了代价估算模型来进一步判断是使用排序还是Hash聚集操作来优化EXISTS语义，经过选择，认定Hash聚集代价小于排序，因此选定了HashAggregate  作为其查询执行计划

Seata 整合多数据源dynamic-datasource-spring-boot-starter | Spring Cloud 60
gmHappy
06-30 1万+
在这篇文章中，我们使用Seata整合一下多数据源的场景。多数据源切换的功能我们使用`dynamic-datasource-spring-boot-starter`来完成，并且这个组件还可以和`Seata`进行整合，实现数据源的代理。
MyBatis Dynamic SQL基本使用
JAVA开发区的博客
04-18 3357
该类用于定义表。表定义包括表的实际名称（如果使用，包括模式或目录）。如果需要，可以在select语句中应用表别名。您的表应该通过扩展类来定义。该类用于定义库中使用的列。Java 类型实际的列名（可以在 select 语句中应用别名）JDBC 类型（可选）如果不需要默认类型处理程序，则在 MyBatis 中使用的类型处理程序的名称} } }JDBCType;} } }
ToprowDB Dynamic Server 查询优化技术---子查询优化--03-3
那海蓝蓝的博客
03-13 385
3.1.3 Q3 select * from (select age as age2 from test2) as temp,test1; 3.1.3.1 ToprowDB QUERY: (OPTIMIZATION TIMESTAMP: 08-15-2016 18:22:17) ------ select * from (select age as age2 from test2),te
Greenplum数据库执行器——DynamicSeqScan执行节点
肥叔菌的博客
03-28 391
从上述执行计划对比可以看出，Postgresql优化器中每个分区子表都对应一个SeqScan，并由Append节点串联；而再ORCA优化器中，Dynamic Seq Scan则包含了分区裁剪后所有分区子表的扫描动作。这里主要描述Dynamic Seq Scan的执行流程，后续会关注Partition Selector节点。用于将DXL dynamic table scan节点转化为DynamicSeqScan节点，以提供给执行器执行。
高级sql技巧
qq_52380715的博客
02-17 1582
【代码】高级sql。
postgresql 数据不多却很慢，seq scan的问题
华 英雄
10-13 2439
What is the difference between Seq Scan and Bitmap heap scan in postgres optimization - What is the difference between Seq Scan and Bitmap heap scan in postgres? - Stack Overflow where条件里用in的时候，有时候使用seq scan反而会导致異常慢，可以指定关掉 SET ENABLE_SEQSCAN to OFF;
SQL Server 2008查询性能优化 源代码
01-08
在SQL Server 2008中，查询性能优化是一项至关重要的任务，因为它直接影响到数据库系统的响应速度和整体效率。"SQL Server 2008查询性能优化源代码"这一资源提供了一种深入学习和实践的方法，帮助我们理解并提升SQL...
SpringBoot 多数据源 - dynamic-datasource | 快速入门
甘蓝的专栏
03-20 2855
基于 SpringBoot 的多数据源 - dynamic-datasource 快速入门。
多数据源 - dynamic-datasource | 进阶 - 手动切换数据源、无注解切换数据源
甘蓝的专栏
03-25 2850
基于 SpringBoot 的多数据源实现，手动切换数据源、无注解切换数据源案例。
dynamic-datasource-spring-boot-starter实现SpringBoot多数据源集成
资源摘要信息:"dynamic-datasource-spring-boot-starter是一个基于Spring Boot框架的快速集成多数据源的启动器。它支持Jdk 1.7 +，SpringBoot 1.4.x 1.5.x 2.xx版本。dynamic-datasource-spring-boot-starter支持...
GPOrca中连接查询的快速优化
Greenplum中文社区
01-22 518
连接优化是查...
PostgreSQL数据库并行查询——工作原理和机制
肥叔菌的博客
09-27 3083
大数据时代，人们使用数据库系统处理的数据量越来越大，请求越来越复杂，对数据库系统的大数据处理能力和混合负载能力提出更高的要求。PostgreSQL 作为世界上最先进的开源数据库，在大数据处理方面做了很多工作，如并行和分区。 PostgreSQL 从 2016 年发布的 9.6 开始支持并行，在此之前，PostgreSQL 仅能使用一个进程处理用户的请求，无法充分利用资源，亦无法很好地满足大数据量、复杂查询下的性能需求。2018 年 10 月发布的 PostgreSQL 11，在并行方面做了大量工作，支持了并
相关子查询和嵌套子查询 [SQL Server]
weixin_30470857的博客
10-20 336
SQLServer子查询可以分为 相关子查询 和 嵌套子查询 两类。前提，假设Books表如下： 类编号图书名 出版社价格--------------------------------------------------------2 c#高级应用 圣通出版 23.002 Jsp开发应...
使用FetchXML制作Dynamics CRM Online 高级报表
GhostHouse
02-02 4324
今天给大家分享一篇关于制作报表的文章，今天我们不用SQL来做报表，我们用FetchXML来做。这次我们的测试环境是Dynamics CRM Online，大家应该知道，Dynamics CRM Online只能部署基于FetchXML制作的SSRS报表。既然说到了高级报表，那肯定是有它的卖点:这里的高级是指，我们的报表可以通过CRM 高级查找界面去定义数据源，不像普通的SSRS报表，数据源都是固定
PostgreSQL查询优化器--逻辑查询优化--视图优化（一）
dongdong_java的专栏
01-13 2259
8.1.1 视图重写 PostgreSQL有一个模块，称为规则模块，用以处理规则。规则系统把查询修改为需要考虑规则的形式，然后把修改过的查询传递给查询优化器执行。视图被作为规则的子部分，在此被处理。所以，PostgreSQL通过规则模块（pg_rewrite_query函数）支持逻辑查询优化的视图重写，也就是把视图用视图的定义替代，视图定义在SQL中相当于子查询。PostgreSQL统一对子
《Greenplum5.0 最佳实践 》SQL 转换
weixin_33970449的博客
12-06 271
改变 SQL 查询 Greenplum 数据库是基于代价的查询优化，查询优化器会选择代价最小的作为执行计划。像其他的 RDBMS 优化器一样， Greenplum的查询优化器也会考虑如下因素，例如做连接操作涉及的记录数量，索引是否可用，访问数据的字段基数。查询优化器还要考虑数据的具体位置，尽可能的在当前段内执行更多的操作，然后在进行段之间的通信操作，因为...
750W高PF值充电机电源方案：基于UCC28070、ST6599和PIC16F193X的设计与实现
最新发布
08-08
750W高功率因数（PF）充电机电源设计方案，采用TI公司的UCC28070作为交错式PFC控制器，ST公司ST6599用于LLC谐振变换，以及Microchip的PIC16F193X作为主控芯片。文中不仅提供了详细的原理图、设计文件和烧录程序，还分享了实际调试经验和技术细节。具体来说，PFC环节通过优化乘法器补偿和电流环参数实现了极高的PF值；LLC部分则着重于死区时间和谐振腔参数的精确配置；单片机部分负责状态管理和故障保护等功能。最终方案实测效率达到94%，相比传统方案节能显著。 适合人群：电力电子工程师、硬件开发者、嵌入式系统设计师，特别是对高效电源设计感兴趣的读者。 使用场景及目标：适用于需要设计高性能、高效率充电机的企业和个人开发者。目标是在满足高功率因数的同时，提高转换效率并降低能耗。 其他说明：附带完整的原理图、设计文件和烧录程序，有助于读者快速上手并进行实际项目开发。同时引用了华南理工大学硕士学位论文的相关理论支持，使方案更具权威性和可靠性。
SQL Server 2008查询性能优化源代码分析
标题和描述中提到的知识点涉及到的是SQL Server 2008数据库管理系统中的查询性能优化技术。为了深入理解这个主题，需要掌握以下知识点： 1. SQL Server 2008数据库概述 - SQL Server是微软公司开发的一款关系型...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值