国产数据库优化差距肉眼可见：KES的DISTINCT智能改写深度拆解-编程实验室

国产数据库优化差距肉眼可见：KES的DISTINCT智能改写深度拆解

做开发和运维的朋友应该都有同感，日常写SQL总会习惯性带上DISTINCT做去重。很多时候查询条件已经把数据锁定成唯一值，但普通数据库还是死板执行全表扫描、排序去重，白白浪费服务器性能。

金仓KingbaseES在内核里做了DISTINCT专属智能优化，不靠人工改SQL，数据库自己就能识别冗余去重逻辑，还能自动转换成更轻量的执行方式。今天就结合官方实测文档，从业务痛点、底层原理、实测效果，再到和其他国产类型数据库的优化器逻辑差异，一次性给大家讲透。

平时开发里有很多这种常见场景，明明WHERE条件已经把字段固定成常量，比如a=1 and b=1，结果还是加上了DISTINCT。

这种语句从业务逻辑上看，本来就只会返回单条数据。但传统数据库不会做逻辑判断，依旧走完全表扫描、排序、哈希去重整套流程。数据量越大，冗余的计算开销就越明显，很容易拖慢接口响应速度。

还有多表关联的场景，通过INNER JOIN等值条件就能锁定唯一数据，很多人还是习惯性加DISTINCT，进一步放大了性能损耗。

而且这类SQL优化还有两个绕不开的难点：
第一是语义安全，改写之后必须保证查询结果完全一致，不能乱改逻辑；
第二是常量判定，要能识别WHERE约束、关联条件、多谓词推导等多种固定字段的场景，普通优化器很难做到全覆盖。

KES把冗余DISTINCT优化归纳成两种落地方式，都是在内核自动完成，不用人工干预。

KES支持通过GUC参数控制开关，符合条件的DISTINCT语句，会直接改写成GROUP BY执行。

这么做的实际好处挺多，能借助GROUP BY自带的主键键值裁剪能力，还可以启用数据库并行执行机制。原本要对整组字段去重，改成基于主键分组，直接砍掉多余的计算步骤。

官方实测数据很直观：
优化前查询耗时464ms，开启自动改写之后，直接降到249ms，性能提升幅度很明显。

这是最实用的一项优化。当WHERE条件、多表关联条件能把查询字段固定为常量时，结果集最多只有一条数据。

KES优化器识别到这种情况后，会直接把DISTINCT或者GROUP BY替换成LIMIT 1。不用扫描全表，找到第一条符合条件的数据就直接返回。

单表示例优化前后对比：

就算是多表关联复杂语句，效果同样突出：

selects1.a,s2.bfroms1innerjoins2ons1.a=s2.bands1.a=5groupbys1.a,s2.b;

优化前耗时12ms，优化后仅0.08ms，差距特别大。

简单说，这种优化把“全表遍历去重”改成“匹配到即终止”，砍掉了大量无效扫描操作。

KES能精准识别字段固定的场景，靠的是编译原理里的常量传递和谓词传递技术。

优化器会先把整条SQL拆解，搭建完整的逻辑表达式树。把查询字段、过滤条件、多表关联关系全部拆成节点逐一解析。
再通过常量传递，把WHERE里的固定数值同步到查询列；通过谓词传递，把过滤条件推导到关联表字段。

走完整套逻辑推演，优化器就能确定：现有条件已经决定结果唯一。既然不会产生重复数据，DISTINCT自然就是冗余逻辑，可以直接替换简化执行流程。

这也是很多选型和调优人员关心的点，同样是国产数据库，优化器的逻辑推理能力差距其实很大。

拿其他国产数据库做同语句实测：
执行带常量约束的DISTINCT查询，select distinct a,b from distinct_1 where a=1 and b=1;
其他国产数据库依旧按照标准DISTINCT流程执行，完全没有识别出冗余逻辑，也不支持自动转LIMIT 1优化。

从底层逻辑来看差异更明显：

传统优化器（含DM这类）
只做基于代价的计划选择，只会对比不同执行方案的开销选最低的。没有深层逻辑推导能力，识别不了常量固定、谓词传递这类隐性场景，写了DISTINCT就一定执行去重。
KingbaseES现代优化器
不只是看执行代价，还具备自主逻辑推理能力。能构建表达式树、做常量谓词推导，主动识别冗余语法并在内核改写。从根源减少排序、哈希、全表扫描的多余开销。

这也能看出，部分国产数据库还停留在基础代价优化阶段，而KES已经具备了深层逻辑改写的能力，在复杂SQL适配和性能优化上更有优势。