谁是最强六边形战士（集中式SQL完结篇）

发布时间：2025-11-05 13:48:07 来源：创站工坊 作者：系统运维

近期针对国产集中式数据库的最强战士SQL能力，做了些评测工作，边形也分多期进行了分享。集中本篇是完结对之前输出内容的一个总结。其实SQL能力包含的最强战士范围很广，还有许多未测试的边形部分。受限于个人精力，集中先早告一段落做个总结。完结这个特别声明下，最强战士因国产数据库的边形发展很快，上述测试内容代表某一版本能力，集中仅供用户选型时作为参考。完结之前也有厂商联系我，最强战士在最新版本中有了很大增强，边形后续我将在这个平台更新厂商的集中最新功能改进。

1. SQL能力评测整体表现

在展开说明之前，先回顾下整体测试方案。

❖ 评测对象架构：集中式

从数据库架构上看，考虑到分布式与集中式的差异较大，本次将重点放在集中式数据库上。从之前接触用户到第三方调查机构的报告来看，数据库的集中式架构仍然是主流架构，占据近八成左右的云南idc服务商市场份额。因此选择以集中式数据库为评测对象。

❖ 评测功能标准：Oracle

长期以来，Oracle 数据库一直是数据库业内的标杆性产品，特别是在集中式数据库领域。因此，本次测试会以Oracle 的能力为标准与国内数据库进行对比。此外，考虑到国内大部分已有业务也都是基于 Oracle 去开发的，因此迁移到国产数据库采用与Oracle为参照物也具有很好的参考意义。

❖ 评测产品范围：主流+代表性

国内数据库厂商及产品非常多，选择哪些厂商及产品是个很头疼的事情。这里本着主流或有代表性的原则进行选择。从现有集中式数据库的市场占有率方面，选择头部的厂商达梦、电科金仓为代表。从生态方面选择 openGauss 生态的海量数据；MySQL生态上没有太好选择，故使用最新社区版本；PG 生态上由之前的电科金仓来代表。自研方面，服务器租用则采用的崖山数据库，毕竟其主打也是Oracle的兼容能力。最后也选择 Oracle 在国内仍然大规模使用的版本作为参照对象。

❖ 评测版本&配置

采用官方Docker镜像，在未做优化下进行测试。具体版本如下

基于之前的测试结果，将整体各个数据库的支持能力从1~5分进行打分后，整理为如下表格。

从上述这个表格里，可对各个数据库对SQL支持能力有个全面的了解。为更清晰的表现出数据库的综合能力，我通过下面的雷达图更为清晰地表达下。

Oracle，作为对标对象，其整体表现是最为全面的，也是其他数据库的标杆。MySQL，作为最流行的开源数据库，服务器托管在很多互联网类应用上得到大量使用，但在更能反映其企业级应用支持的SQL能力上，表现差强人意。特别是在关联、排序、视图和逻辑优化等方面，都存在较为明显的短板。DM，则作为老牌国产数据库厂商，各方面能力表现比较全面，这也是达梦在国内替换 Oracle 等方面表现出色的原因之一。KingBase和Vastbase，情况比较类似，前者是基于PG、后者是基于openGauss做了大量优化的产品，在基础能力上表现也都非常出色。YashanDB，作为数据库领域的后来者，近些年发展迅速，其整体评测下来的表现很惊艳；特别是其使用体感（如执行计划）几乎与Oracle无异，这点很赞！总体来看，国产数据库的综合表现都是不错的，可以承担起企业核心业务场景，在具体细分方面还各有不足，需要在未来长期补强。值得欣慰的是，这方面国产数据库也都看到了自己的短板，正在快速追赶中...

2. SQL能力评测分项说明

访问路径，主要看数据库通过表或索引访问数据时，支持的访问方式。更多、更丰富的访问方式，代表可能采取更为高效的方式来访问数据。针对这方面，国产数据库表现差异较大，特别是针对索引的访问方式。

针对表连接的情况，主要是看数据库采用何种执行计划来完成。在在同样架构、同等数据规模，都收集统计信息的情况下，不同数据库在选择嵌套循环、排序合并还是哈希关联上，效率还是差异挺大的。针对这方面，国产数据库表现差异不大，针对三种关联方式大多支持，但在具体的选择使用上，还是存在不同。

❖ 子查询支持情况

子查询根据其所处位置、与主查询关系、结果集形式及含有谓词情况，分为多种类型。考察一个要点，就是数据库对上述子查询不同种类的支持情况。针对这方面，国产数据库都已支持。

❖ 子查询优化

子查询有多种优化方式，包括子查询展开、子查询合并、子查询推入、谓词迁移等。其核心目的：一是尽量不使用子查询，将其与外侧查询一起处理，这样更优；二是如果不能展开，则将更多的条件能放入子查询内执行，尽早减少数据规模，达到优化目的。针对这方面，国产数据库表现尚待提高，针对包含多层嵌套的子查询，表现较Oracle差距还是很大。

❖ 排序

排序，是数据库内比较消耗资源的一类操作，特别是在结果比较大的情况下。因此在数据库处理上，应尽量规避排序的行为。在上面这些操作中，有些是为了进行排序，有些是为了其他目的（如去重等）；因此数据库是可以考虑优化此类排序行为的。例如Oracle数据库，在10g以前的版本是通过SORT GROUP BY完成分组的，但在10g之后默认提供了HASH GROUP BY，这样效率更高，当然其结果集不保证有序了。针对这方面，国产数据库表现差异较大，针对不同排序需求，所能采取的优化手段在选择上存在差异。

❖ 分组聚合

数据库中的分组聚合是两类操作：分组操作是指用SQL语句将一个结果集分为若干组，并对这样每一组进行聚合计算；聚合操作则是基于多行记录返回数据数据:平均、最大、最小值等，聚合操作必须处理输入数据的每一行记录，因此通常和全表扫描联系在一起。针对这方面，国产数据库大多已支持。

❖ 视图优化

视图优化，是指针对语句中存在视图的情况采取的优化手段，包括有视图合并、条件推入、视图重写等情况。视图合并，是指对于存在复杂视图的查询，优化器可以有两种方式来优化查询。一是创建一个用于聚集视图合并结果集，并把这个结果集连接到基表中；另一个是展开视图连接两个基表并聚集这些连接。条件推入，则是指在无法执行视图合并的情况下，将读取查询中的查询条件推入到视图查询中去。视图重写，则是将对视图的引用重写为对基本表的引用。视图重写后的SQL多被子查询进行进一步优化。针对这方面，国产数据库表现差异不大，针对视图合并类的优化还有较大差距。

❖ 谓词改写

谓词重写，又称为等价谓词重写，是指将原执行效率低的谓词改写为效率高的谓词并重写SQL，从而提高SQL的整体执行效率的一种优化手段。其本质是在于不同谓词的处理效率存在差异所导致。针对这方面，国产数据库表现参差不齐，主要看内部处理效率，改写倒不一定效率就很高。

❖ 条件化简

条件化简，是指将语句中的条件子句部分优化，选择执行代价更小或更容易利用到索引、约束等的情况。条件子句优化的本质是:尽早推知运算的结果以有利于对元组数进行计算，使得根据代价估算模型(元组数是重要的计算依据)可以准确地推演出最优查询执行计划。针对这方面，国产数据库表现差异较大，针对可能的化简条件很多还未支持。

❖ 连接消除

在多表连接的过程中，查询优化器可以找出多表连接的最优查询执行计划，这意味着多个表的最优的连接次序被确定。如果根据表的连接次序确定析取条件的优先判断次序，存在加速判断的可能(处于表达式后面的条件可能不用判断了)。针对这方面，国产数据库表现差异较大，有些消除方式还不支持。

❖ 索引优化

如果语句中不仅包含有Select（选择）、Project（投影）、Join（连接） 三种基础操作，还有其他类操作（如分组等）。此时，优化器是可以根据索引进行一定的优化。针对这方面，国产数据库表现差距明显，还有较大提升空间。

相关文章