SQL优化之列裁剪和投影消除

  列裁剪

  对于没用到的列,则没有必要读取它们的数据去浪费无谓的IO

  比如我们有一张表table1,它含有四列数据(a,b,c,d)。当我们执行查询select a from table1 where c 10时,我们可以清晰的看到,table1中只有a,c两列被用到了。分别是Selection算子用到c列和Projection算子用到a列。那么DataSource读取数据时,b,d两列则不需要读取,可以裁剪掉。

  那么都有哪些算子与列有关系呢?综合我们多年来使用SQL的经验来看,Selection(Where 条件)、Projection(搜索的列)、Sort(排序列)、Join(等值连接)、Aggregation(Group By及相关聚合操作)等。

  列裁剪的算法就是自顶向下的把算子过一遍,某个节点需要用到的列就等于它自己需要用到的列加上它的父节点所需要用到的列。这样得到整个SQL语句所涉及到的列,从而再读取数据时只读取需要的列即可。

  列裁剪通过只读取需要的数据减少IO操作来达到优化的目的

  投影消除

  投影消除是把不必要的Projection给消除掉

  那么问题来了,什么情况下,投影算子是可以被消除的呢?

  如何Projection算子需要投影的列跟子节点的输出列一样,那么这个投影就是一个废操作,可以被消除掉。比如说:select a,b from table1 如果再表table1中刚好只有a,b两列,也就是DataSource的输出和Projection需要投影的列一样,那么这时候就没必要在TableScan之后再做一次Projection操作了。

  如果Projection的子节点还是Projection的话,那么子节点的Projection就没有意义了,可以干掉。如:select a from (select a,b,c from table2) 这条语句里面有两个Projection,分别是最上层的Projection(a)和它的子节点Projection(a,b,c)。那么Projection(a,b,c)这个节点就是废操作,可以被消除掉。

  Aggregation在某种意义上也属于投影操作,因为从这个节点出来的都是列的概念,比如Max(a)、Min(b)等。因此在Aggregation-Projection的过程中,这个Projection也是可以被消除掉的。

  所以说,一个节点是否可以被消除,一方面是由它的父节点告诉它,它是否是一个冗余的Projection操作。另一方面是它自己和孩子节点做比较,看自身是否可以被消除。

  public void eliminate(Plan plan, boolean canEliminate) {

  //如果plan为Projection则判断是否需要被消除

  if (plan is Projection) {

  //如果父节点调用时指定canEliminate为true,则进行消除操作

  if (canEliminate) {

  doEliminate(plan);

  }

  //如果plan的输出和子节点的输出一样则消除plan

  if (checkPlanOutEqualsNext(plan)) {

  doEliminate(plan);

  }

  }

  //递归调用,遍历子节点

  eliminate(plan.next(), checkPlanNextCanEliminate(plan));

  }

  最大最小消除

  最大最小消除严格上说不是标准逻辑优化里面需要做的事情

  举个栗子:

  语句1select min(a) from table1可以转换为语句2select a from table1 order by a desc limit 1

  语句1生成的逻辑执行计划是一个 TableScan 上面接一个 Aggregation,也就是说这是一个全表扫描的操作。

  语句2生成的逻辑执行计划是TableScan + Sort + Limit,在某些情况,比如a是主键或者是存在索引,数据本身是有序的, Sort 就可以消除,最终变成 TableScan 或者 IndexLookUp 加 Limit,这样子就不需要全表扫了,读到第一条数据就得到结果!全表扫跟只查一条数据,查询速度可是天壤之别。也许这一点点写法上的区别,就是几分钟甚至更长,跟毫秒级响应的差距。

  最大最小消除就是SQL优化器自动把上面的操作实现了。比如说:

  select max(id) from table1 生成的查询计划会变成下面这种(最大消除):

  select max(id) from (select id from table1 order by id desc limit 1 where id is not null) t

  select min(id) from table1生成的查询计划会变成下面这种(最小消除):

  select min(id) from (select id from table1 order by id limit 1 where id is not null) t

  然后转换后的语句再经过其他的转换规则最终得到最后的查询计划。

?

原文地址:https://www.cnblogs.com/qfjavabd/p/10407068.html

时间: 2024-11-08 22:59:30

SQL优化之列裁剪和投影消除的相关文章

转 sql 优化

1.关于SQL查询效率,100w数据,查询只要1秒,与您分享: 机器情况p4: 2.4内存: 1 Gos: windows 2003数据库: ms sql server 2000目的: 查询性能测试,比较两种查询的性能 SQL查询效率 step by step -- setp 1.-- 建表create table t_userinfo(userid int identity(1,1) primary key nonclustered,nick varchar(50) not null defa

Oracle 建立索引及SQL优化

Oracle 建立索引及SQL优化 数据库索引: 索引有单列索引 复合索引之说 如何某表的某个字段有主键约束和唯一性约束,则Oracle 则会自动在相应的约束列上建议唯一索引.数据库索引主要进行提高访问速度. 建设原则: 1.索引应该经常建在Where 子句经常用到的列上.如果某个大表经常使用某个字段进行查询,并且检索行数小于总表行数的5%.则应该考虑. 2.对于两表连接的字段,应该建立索引.如果经常在某表的一个字段进行Order By 则也经过进行索引. 3.不应该在小表上建设索引. 优缺点:

[转]Oracle DB 通过SQL 优化管理性能

? 将SQL 优化指导用于: – 确定使用资源最多的 SQL 语句 – 优化使用资源最多的 SQL 语句 ? 使用SQL 访问指导优化工作量 SQL 优化 SQL 优化进程 ? 确定没有很好地优化的SQL 语句. ? 优化各条语句. ? 优化整个应用程序. 一般情况下,效果最明显的优化工作是SQL 优化.没有很好地优化的SQL 会不必要地使用过多资源.这种低效率会降低可伸缩性.使用更多的OS 和数据库资源并增加响应时间.要对没有很好地优化的SQL 语句进行优化,必须先确定这些语句,然后再进行优化

《跨 界 之SQL、PL/SQL优化指南》目录下

目 录 三. 常见不合理的语句........................................................100   3.1). 没有使用绑定变量....................................................100   3.2). 隐含转换............................................................101   3.3). 索引列上进行运算...........

SQL优化的若干原则

SQL语句:是对数据库(数据)进行操作的惟一途径:消耗了70%~90%的数据库资源:独立于程序设计逻辑,相对于对程序源代码的优化,对SQL语句的优化在时间成本和风险上的代价都很低:可以有不同的写法:易学,难精通. SQL优化:固定的SQL书写习惯,相同的查询尽量保持相同,存储过程的效率较高.应该编写与其格式一致的语句,包括字母的大小写.标点符号.换行的位置等都要一致 ORACLE优化器:在任何可能的时候都会对表达式进行评估,并且把特定的语法结构转换成等价的结构,这么做的原因是要么结果表达式能够比

SQL优化笔记—CPU优化

补充:常规服务器动态管理对象包括,下面有些资料可能会应用到 dm_db_*:数据库和数据库对象dm_exec_*:执行用户代码和关联的连接dm_os_*:内存.锁定和时间安排dm_tran_*:事务和隔离dm_io_*:网络和磁盘的输入/输出 优化性能的常用方法是检索速度最慢的查询构成您 SQL Server 实例上的正常. 每日工作负载的一部分,然后调整它们,一个接一个的"Top 10"列表. 跟踪会话. 请求 和 SQL Server 基础架构中的最耗费大量资源,查询和执行时间最长

转://从一条巨慢SQL看基于Oracle的SQL优化

http://mp.weixin.qq.com/s/DkIPwbDKIjH2FMN13GkT4w 本次分享的内容是基于Oracle的SQL优化,以一条巨慢的SQL为例,从快速解读SQL执行计划.如何从执行计划中找到SQL执行慢的Root Cause.统计信息与cardinality问题.探索性能杀手Filter操作.如何进行逻辑重写让SQL起飞等多个维度进行解析,最终优化巨慢SQL语句,希望能够抛砖引玉,和大家一起探讨SQL优化方法. 另外,还简单介绍了两种解决疑难SQL优化问题的工具:1005

hive sql 优化

sql优化: ---------------------------------------------------------------- 数据倾斜的处理方式: -- Q: 活动数据 和 对应的维表进行关联,其中某个活动特别的大. A: 1) 给关联健加入一个随机的 1-10的值 2)将维度表 的关联健, 每个加上 1-10的值,将维度表扩充十倍. 3)然后将2个表进行join,从而来消除数据倾斜. -- 尽量不使用count distinct 1) 通过select子查询优化 2) 通过建

数据库优化 - SQL优化

前面一篇文章从实例的角度进行数据库优化,通过配置一些参数让数据库性能达到最优.但是一些"不好"的SQL也会导致数据库查询变慢,影响业务流程.本文从SQL角度进行数据库优化,提升SQL运行效率. 判断问题SQL 判断SQL是否有问题时可以通过两个表象进行判断: 系统级别表象 CPU消耗严重 IO等待严重 页面响应时间过长 应用的日志出现超时等错误 可以使用sar命令,top命令查看当前系统状态. 也可以通过Prometheus.Grafana等监控工具观察系统状态.(感兴趣的可以翻看我之