引言
《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个启发式规则，前后都是有相互依赖，加错地方就是负优化，现在回想一下都是头皮发麻。
总结
cbqt只是帮你找到最准，最优的变换，框架自身并不会降低SQL时延，但具体的变换规则能。cbqt框架的价值在于当你有很多规则，它通过代价估算评估是不是要应用这条规则。当我们精力有限，可有优先搞定如下ROI高的变换。
各种规则收益
其中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版并行查询的产品功能介绍。
