论文解读｜从论文到工程实现：PolarDB Cost Based查询改写

我欲只争朝夕

发布于 2023-7-11 15:26

浏览

0收藏

引言

《Cost-Based Query Transformation in Oracle》^[1]这篇论文是Oracle 2006年放出来的，很详细介绍Oracle是怎么做基于代价的查询变换，知乎的梁老师有篇深度解读《henry liang：Cost-based query transformation in Oracle》^[2]，有兴趣的同学可以自行了解。但论文只是介绍了一下思想，到具体的工程实现还是有很大的gap，本文试图补齐这些gap。

先抛出一个问题，论文中介绍了大量的启发式变换规则，和cost-based变换规则，如何组织它们，制定顺序？本人以前有幸在presto里面加过一些变换，里面林林总总快100个启发式规则，前后都是有相互依赖，加错地方就是负优化，现在回想一下都是头皮发麻。

Oracle规则变换图

论文解读｜从论文到工程实现：PolarDB Cost Based查询改写-鸿蒙开发者社区

Oracle规则迭代器

先申明一下，该图是某位Oracle资深DBA Riyaj某次演讲总结多年tracing经验披露出来的，但他毕竟不是相关功能开发人员，我们可以选择性吸收，先解释一下上图各种缩写：

CSE: Common Subexpression Elimination 公共表达式消除

eg. where (c1=3) or (c1=3 and c2='A') => where (c1=3)

CNT：count(col) to count(*) transformation；count(col)变成count（*），不取值

OBYE：order by elimination

JE：Join Elimination

SU：subquery unnesting

FPD：filter push-down

CVM：complex view merging

JPPD：join predicate push-down

SJC：Set Join Conversion

PM：predicate move-around

GBP：groupby placement

kkoqbc：是个cbo optimizer之类的

如果各位对于这些变换规则不是很了解，可以查阅本文最后规则示例加深了解。

可以从上图看到Oracle把规则整体划分为两部分启发式规则的，基于代价的，启发式规则变换前做一次就可以了。基于代价的规则是会多轮迭代的，如有必要才会再次apply 启发式规则，如做完JPPD，接着再次apply了JE/CNT这些启发式规则。

强调一下，规则放置的位置是很重要的，你看上图SU后面跟着CVM规则。展开说一下，做了SU，有种解法会产生derived table，紧跟着CVM，CVM才有用武之地，apply cvm前提是得有derived table。如果你从0到1做一个cbqt框架，不妨参考上述的规则放置顺序。

Transformation interaction

规则放置整体是按序平铺的，但个别规则之间要考虑交织，互斥的关系。

● 按序平铺(Sequential order)

▷ 规则之间是逐条Apply，直到满足退出条件，比如进死胡同statement变无可变，或者timeout了。但针对单条规则，每个query block都要应用这个rule，sql statement都应用完rule才能应用下一条。

▷ 只要apply当前规则比原sql cost小就应用 eg. Cost(QB) = 60; Cost(SU(QB)) = 30, 应用SU。

● 交织（interleaving)

▷ 规则是交织在一起的，一个query block应用完一个规则即可尝试去应用下一个规则，并不要求sql stmt应用完整条rule

▷ 举个[cvm+su rule组合]的例子来决定是否应用su, 一个Query block只应用su的话代价比原始的大，但紧接着应用CVM代价变小了，更优了，这时候是可以应用SU的，如果仅排律第一条按序平铺的话，就错过了SU这条规则。

cost(QB)=40;Cost(SU(QB)=50; Cost(CVM(SU(QB)))=30 => do SU

● 互斥(juxtaposing)

▷ GBVM（CVM里的一种）跟JPPD规则是互斥的，GBVM会消除view，外层增加更多的groupby列+join condition。JPPD是把外层的view相关join condition下推到view内部，明显是互斥的，所以二者取其一。

▷ Cost(QB) = 60; Cost(GBVM(QB)) = 45; Cost(JPPD(QB)) = 35 implies No GBVM, 虽然GBVM规则放置在前。

Transformation detail

● 识别object

每个sql statement可能会有很多object，比如对于SU规则来讲，子查询就是一个个object，遍历整个stmt，得到整个规则所有object。

● Apply Rule

尝试对每个object去应用规则，每个规则有自己的特性，选择先序还是后序。

自底向上（先序）：比如SU就是先序，从最内层一层层往上消解子查询。cvm亦是如此。

自顶向下（后序）：比如FPD，算子下推，一层层推到最内层。

● cbo

cbo过程除了常见的做join order+算代价外，仔细观察Riyaj的ppt，可以发现oracle cbqt过程中每个query block都有一个签名，如果一个query block没发生什么变化，可以复用之前算好的cost，不必每次都重新计算一遍。

● 搜索空间算法

略，oracle论文讲的很详细，如(two pass, linear, Exhaustive）

总结

cbqt只是帮你找到最准，最优的变换，框架自身并不会降低SQL时延，但具体的变换规则能。cbqt框架的价值在于当你有很多规则，它通过代价估算评估是不是要应用这条规则。当我们精力有限，可有优先搞定如下ROI高的变换。

论文解读｜从论文到工程实现：PolarDB Cost Based查询改写-鸿蒙开发者社区

各种规则收益

其中SU变换增益最大，平均能提升3.8倍，这指导我们可以多花精力在消除子查询上。MySQL SU变换也是比较少的，只有常见的转derived table，spj子查询转semi join。但PolarDB MySQL版将大大增强这部分，后续会有更多技术内幕披露，敬请期待。

此外，一些变换规则确实需要日积月累，对关系代数有深的理解，这也是数据库资深从业者的福音。可以看看SJC变换规则，那是相当复杂了。Oracle做了很多很复杂SQL的变换，举个GBVM的例子，Oracle支持带groupby的view merge，对比之下MySQL是不支持的，仅支持简单的spj的view merge，离Oracle还有很大的距离。

PolarDB MySQL相关工作介绍

云原生数据库PolarDB已经实现了cbqt，但仍需要更多变换规则配合，这是一个长期改进的项目，目前我们在不断加入更多的变换规则，相信在不久的将来，对于复杂的查询，我们也能成倍的降低时延，给用户一个丝滑体验。另外，产品在并行计算ePQ（多核，多机）方面有非常大的查询性能改进，是关系型云数据库里面的领导者，对于同类竞品AWS Aurora有代差上的领先程度。附上官方渠道发布的性能数据，ePQ版本比原生MySQL单条执行最大提升150倍，以下是云原生数据库 PolarDB MySQL版并行查询的产品功能介绍。

（https://help.aliyun.com/document_detail/426501.html）

论文解读｜从论文到工程实现：PolarDB Cost Based查询改写-鸿蒙开发者社区