对国产数据库厂商提几个关于SQL引擎的小需求

国产数据库迎来了一个高速发展的好时期，大量的企业用户正在将他们的数据库系统迁移到开源和国产数据库平台上。不过我们的国产数据库厂商在大量收割用户和“数钞票”的时候，广大的用户也在期盼着国产数据库变得更好用。SQL引擎是数据库最为核心的组件之一，因此大量国产数据库厂商在内卷竞争的时候，也需要能够做出一些让广大用户满意的功能来。

我们团队常年从事系统优化和数据库运维工具开发，这些年也接触了大量的用户，遇到过大量的数据库的坑，其中大部分是和SQL引擎有关的。因此今天我也代表广大的用户，给国产数据库提出一些关于SQL引擎方面的功能需求。希望在新一个版本的国产数据库中，能够看到这些功能被逐步实现了。

如果最希望国产数据库SQL引擎具有的功能就是全功能的HASH JOIN，大家都知道HASH JOIN是解决大数据量的表关联问题的最有效的连接方式。Oracle的HASH JOIN很强大，大量复杂的连接条件，都可以通过HASH JOIN来摆平。虽然现在很多开源、国产数据库都支持HASH JOIN，不过对HASH JOIN的支持上依然存在很多的盲点。如果遇到某些情况下，正好HASH JOIN无法使用，那么这条SQL就只剩下改写一条路了，这对于开发人员和DBA来说就是灾难。

第二个需求是SQL指纹和执行计划指纹

SQL指纹和SQL ID不完全是一回事，SQL ID只能指向一条唯一的SQL语句，而SQL指纹可以将一组存在略微差异的SQL语句归类为一种SQL。比如我们有一条SQL，除了某些大小写不同，其他是相同的，或者只有某个变量不同，其他是相同的，那么这些不同的SQL应该是同一条SQL，虽然这些SQL的SQL ID可能不同，不过这些SQL具有相同的指纹信息。通过这些指纹可以找到这类相同的SQL，进行统一的分析。

执行计划指纹是指完全相同的执行计划，有可能不同SQL ID的SQL会使用相同的执行计划，在SQL中会有一个执行计划指纹的标识，指向这个执行计划。通过“执行计划指纹”，我们可以减少保存在内存中的执行计划数量，不管是否实现了全局执行计划，都可以将执行计划存储在一个共享内存区域中，供监控分析人员使用。类似的SQL指纹与执行计划指纹的功能实际上在Oracle数据库中大多数已经实现了，有兴趣的朋友可以去研究一下。

第三个需求是HINT

优化器的提升是相当困难的，需要大量的资金投入和时间的沉淀才可以做得越来越好，绝对无法依靠某几个聪明的高手就可以完成。如果遇到了CBO优化器真的无法做出正确判断，非要使用错误的执行计划的时候，开发人员还是可以通过HINT来强制矫正执行计划的。目前也有一些国产数据库和开源数据库支持hint了。不过在实现方法上，很多国产和开源数据库是通过外挂方式，利用数据库代码中的钩子来实现的，另外HINT支持的操作也还不是很完整。

通过钩子的插件实现方式还是没有原生态的内核支持效率更高，在内核中直接支持丰富的HINT绝对是提升国产数据库SQL解析效率的必然途径。在HINT支持的操作方面，HINT不仅仅可以强制指定某种执行方案，还可以实现集群计算环境中的强读写分离、弱读写分离等功能。比如设定集群计算环境中MASTER选择的策略，以及指明某操作可以放置于只读节点，甚至指明某个操作是弱一致性操作，运行数据延时的最大限制等。这些HINT往往需要集群计算环境被纳入到数据库的内核中，而不仅仅是外挂的。

第四个需求是OUTLINES的原生态支持

当我们无法直接修改SQL，添加HINT来强制指定一个比较优化的执行计划的时候，就只能依靠OUTLINES了。传统的OUTLINES只能针对某个SQL ID，如果存在一些没有使用绑定变量的情况，就没办法通过SQL ID来指定OUTLINES。而往往一个系统中，这些SQL才是最常用的，也是最重要的。在OUTLINES的实现上，如果可以通过SQL指纹来设定，那么OUTLINES将会有更广泛的用途。

第五个需求是长时间运行的SQL执行进度可视化

提供一个类似于Oracle V$SESSION_LONGOPS的外部接口视图。不过希望能够比Oracle提供更多一些的信息。比如当前这个操作来自于哪个执行计划（执行计划指纹），以及这个操作处于执行计划的第几个步骤。当然这种SQL执行进度可视化仅仅显示长时间执行的操作，只有当执行计划中的某个算子执行成本超过一定阈值的时候，才需要输出到接口中，否则这种输出会影响SQL引擎的效率。这部分功能实现只要到某个算子级别就可以了，不需要做SQL级别的，SQL引擎还是性能为先，可视化是次要的。

其实SQL引擎中的优化器是改进难度最大的部件，需要有大量的应用案例来促进其优化和改进。而且有些优化器的功能优化难度极大，要做出一个优秀的CBO优化器其实不是一朝一夕就能够完成的。不过在优化器达到完美之前，必须是够用的。也就是能够尽可能让我们的开发人员不要总是面临SQL不改写就无法正常运行的困境。用户的应用场景十分复杂，因此作为国产数据库的开发者，集中力量去解决必须解决的问题，剩下的问题通过HINT，OUTLINES这样似乎不是太智能化的手段来弥补优化器的能力不足，也是是必须的。不管怎么说，能够解决用户问题的数据库就是好数据库。

点击此处阅读原文

本文分享自微信公众号 - 开源软件联盟PostgreSQL分会（kaiyuanlianmeng）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。