我们团队常年从事系统优化和数据库运维工具开发，这些年也接触了大量的用户，遇到过大量的数据库的坑，其中大部分是和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这样似乎不是太智能化的手段来弥补优化器的能力不足，也是必须的。不管怎么说，能够解决用户问题的数据库就是好数据库。
