诚信为本,市场在变,诚信永远不变... 设为首页|加入收藏|联系我们
24小时咨询热线

0898-08980898

新闻资讯NEWS

联系我们contact us

地址: 海南省海口市

座机:0898-08980898

联系人:李生

手机:13876363636

邮箱:admin@youweb.com

行业新闻

您现在的位置是: 首页 > 新闻资讯 > 行业新闻

HANA SQL优化器介绍

HANA的SQL优化器分为两种,基于规则优化(Rule based optimization)和基于成本优化(Cost based optimization)。先执行基于规则优化,然后执行基于成本优化。 规则优化是一个串行的优化过程,而成本优化是在规则优化之后,并发多种可能并记录最优的那个。基于规则优化是宏观层面的,容易预测到的。而基于成本优化更像是微观层面,会充满变化。

基于规则优化

基于规则的优化将会基于HANA内置的优化规则重写整个执行树,比较经典的比如:

  • 上提select -> 移除多余列 -> 下放select
  • 简化Group By
  • 简化Join

基于成本优化

基于成本的优化会并发分析并比较执行成本,成本是用样本计算得到的,样本大小一般是指样本条目数(使用参数compile_time_sampling_size控制,默认值为1000),也有可能因为数据类型和特殊运算而发生变化。

比如:一个百万条目的表,如果存在数据格式为DOUBLE或者TEXT的列,并且会涉及到ROW_NUMBER或RANK这样的窗口函数,优化器就会尝试下放过滤器来尽可能减少中间表的大小,避免在大量数据上执行窗口函数。

SQL优化的最终目的是缩短执行时间,而当试图得到最优的SQL执行计划时,会对CPU和内存造成额外的负载。所以需要对时间资源和空间资源做好平衡。(比如提高sampling size,会提高找到更优路线的机会,同时也会更加消耗CPU与内存)

基于成本的优化采用枚举的方式寻找最优解,分为两种方式:逻辑枚举与物理枚举。

逻辑枚举

逻辑枚举是对QO树(query optimizer tree)的树型进行各种调整的尝试,比如交换JOIN和聚合的执行顺序,交换JOIN和FILTER(where)的顺序等等。

常见的两种模式:

A_THRU_B: JOIN_THRU_JOIN, JOIN_THRU_AGGR, LIMIT_THRU_JOIN等,是指执行顺序的交换,去看这些顺序变化是否能够缩短执行时间。
PRE_A_BEFORE_B: 最主要是PREAGGR_BEFORE_JOIN,在JOIN之前,预先聚合一部分数据,以减少JOIN的数据量。

物理枚举

逻辑枚举的关注点在FILTER,JOIN,AGGREGATION这些操作的顺序,而物理枚举的关注点在执行引擎的选择,执行的位置等。
选择执行引擎:在语句中指定行引擎或者列引擎是没有用的,因为物理枚举会都试一遍,找到最快的引擎。
执行位置(本地或远程):这一条指的是当HANA作为远程连接时(Smart Data Access,Near Line Storage,Dynamic Tiering),考虑一条语句是在远程库执行还是拿到HANA执行。在这种情况下考虑优化时,尤其需要考虑远端数据库的资源,链路传输速度等问题。

在线客服

关注我们 在线咨询 投诉建议 返回顶部

平台注册入口