zoukankan      html  css  js  c++  java
  • CMU Database Systems

    查询优化应该是数据库领域最难的topic

    当前查询优化,主要有两种思路,

    Rules-based,基于先验知识,用if-else把优化逻辑写死

    Cost-based,试图去评估各个查询计划的cost,选取cost比较小的

    一个sql query的处理流程,

    先是Parser,生成抽象语法树ast,Binder会去做元数据对应,把parse出来的name对应到数据库中的结构,表,字段等

    然后Rewriter就是Rules-based的改写,而Optimizer是cost-based的优化

    Relational Algebra Equivalences

    做查询优化的前提是,查询的结果是不能变的

    无论你查询怎么优化,最终得到的结果是一样的,那么就称他们是,关系代数等价

    对于不同的operator,有些通用的优化rules,

    这里给些例子,

    Selections

    对于selection,尽量下推,谓词下推,尽量早做

    Projections

    projection也是应该尽早去做,不需要的字段就根本不用读出来

    Joins

    对于Join是符合交换律和结合律的,但是对于多表join,你需要尝试的可能性是非常多的

    Cost Estimation

    cost-based的查询优化,关键就是要能够知道cost

    如何预估cost是很复杂的问题

    当前的思路,就是我们会事先对数据表,列,索引做些统计,并存储到catalog里面,然后后面就根据这些统计数据来预估cost

    主要的统计数据,包含两项,行数和每一列的distinct values的个数

    然后有个概念,selection cardinality,两个相除,就是平均每个value多少行

    这里的假设是数据是均匀分布,很naive

    有了这些概念,我们就可以来定义复杂谓词,操作,的selectivity,筛选率

    Equality,Range

    Equality的定义有些confuse,SC(P),SC(age=2)啥意思?

    其实以range的逻辑看,这里就应该是,A列一共有5个值,当前Equality只取其中一个,所以五分之一,就这么简单

    Conjunction和Disjunction

    右图中,应该是 - sel(P1 交 P2)

    Join,对于join,这个cost算的很粗糙,比如R表中的行数 * 每行在S中的cardinality 

    平均分布问题

    当前算cost,都是假设平均分布,这个明显是很不合理的

    但是如果对于每个value都去记录一个统计,明显不可行,太多了

    所以有如下几种近似方法,

    一种,每个value bucket都去统计太多,那就分组,这样每个组记录一个统计,组内仍然假设平均分布
    分组可以有两种方式,第一个是固定bucket数,或者固定组内bucket统计和差不多,叫等宽

    还有种更直接的方式,sampling

    Query Optimization

    上面说的cost estimation的方法都很naive,但是如果我们能准确的预估执行计划的cost,那么如何真正的做查询优化?

    这里分为三种情况,

    Single Relation,Multiple relations, Nested Sub-queries 

    Single Relation,比较简单,单关系表的查询
    所以关键就是选择合理的access method,是顺序扫描,还是用各种索引
    这里有个概念,sargable,数据库专有概念,意思是查询或执行计划可以用索引来优化的
    OLTP的查询往往都是sargable的,所以通过简单的启发式的方式就可以找到优化方法

    Multiple relations

    多关系表join就比较复杂了 

    除了要选择各个表的access method

    还需要选择各个表的join顺序和join算法

    其中选择join顺序是个cost很高的事情,因为可能性和search space会比较的大

    这里介绍IBM R的方法,它把join顺序简化成,只考虑Left-deep tree(右图最左边这个)

    这样search space会大幅缩小,另外特意选择left-deep tree的原因是,这种join结构,比较容易pipeline执行,比如下图,a b的join结果直接可以用于和c join,当中间结果不是很大的时候,不需要不断地的把结果写到磁盘

    对于Multiple relations,可以尝试用动态规划来选择best plan

    更为形象的例子来说明如何逐步筛选plan

    第一步是选择join的顺序,可以首先把明显低效的,比如做cross-products的Prune掉
    然后根据cost model找出best的plan

     第二步是选择join算法,这里有Nested Loop和Hash Join

     第三步是选择access method,

    Nested Sub-queries

    第三种更为复杂一些,在有子SQL的时候,如何优化?

    有两种方式,一种是通过rewrite,把嵌套的子语句flatten掉,如右图的例子

    另一种方法,是decompose,如下面的例子

    子句是要获取最大的rating,这个反复去执行一定是低效的,所以,干脆把这个语句拿出来单独执行,结果放在临时表,然后执行主语句的时候把值填回去

  • 相关阅读:
    2020软件工程02
    自我介绍
    2019年春总结作业
    第十二周作业
    第十一周作业
    第十周作业
    第九周作业
    第八周作业
    第七周学习总结
    第六周学习总结
  • 原文地址:https://www.cnblogs.com/fxjwind/p/10937518.html
Copyright © 2011-2022 走看看