国产数据库内核架构选型实战指南

大家好，我是数据库小学妹 👋

领导让我对比三款国产数据库的内核架构，给公司订单管理系统定方案。我本来只打算跑个基准测试交差。后来发现，内核架构的差异比跑分数据重要得多。

有一款不兼容MySQL的GROUP BY严格模式，业务里的"不规范"SQL全爆了。有一款的备份工具和xtrabackup完全不通用，导出来的备份文件根本用不了。还有一款的优化器选了条我没想到的执行计划，同样的数据量查询慢了三倍。

折腾了一个多月，我从"会用数据库"升级到了"能看懂内核"。今天把这段经历整理出来，希望能帮你少走弯路少踩坑。

什么是数据库内核架构？简单说就是存储引擎、优化器、事务管理器这三件套怎么设计和组合。路线不同，性能、兼容性、运维成本都会跟着变。

两条技术路线怎么选，自研内核还是开源改写

市面上国产数据库大致分两种路线。

第一种是基于开源代码做二次开发。在MySQL或PostgreSQL的代码基础上改存储引擎、改优化器、加安全模块、适配国产芯片。好处是兼容性好，MySQL的SQL语法大部分能直接用，工具链也能复用一部分。我一开始最看好这条路，因为迁移成本最低，团队上手也快。

这条路的问题在于受制于上游。上游发布安全补丁你得跟着合并，上游改了API你的定制代码可能就挂了。深度定制到一定程度后，和上游差异越来越大，合并更新的成本也会越来越高。

我测试中就遇到过上游MySQL修了一个bug，国产数据库合并补丁时和自己的定制代码冲突了，排查了两周才搞定。

第二种是从零开始写自研内核。存储引擎、优化器、事务管理器全部自己写，不受历史包袱限制。但这条路最大的挑战是生态。驱动、管理工具、备份方案、ORM适配，每样都要从头搞。社区也小，踩坑了不容易找到答案。说真的，我一度不太看好这条路，因为生态短板太明显。

我对比的三款数据库，跑分差不多，但拿到业务SQL上一跑，差异就出来了。

存储引擎怎么决定性能，行存列存还是混存

存储引擎决定数据怎么存、怎么读、怎么写。

MySQL的InnoDB是行存引擎，一行数据的所有字段存在一起。分析查询需要读所有行的某几个字段时，行存会把整行数据都读出来，丢掉不需要的列。当表有几十个列、查询只需要两三个列时，IO浪费很高。列存反过来，只读需要的列，但读一行数据要从多个列文件里拼回来，点查效率低。

很多业务既要OLTP又要OLAP，白天跑交易晚上跑报表。MySQL体系下常见的做法是把数据导到列存数据库里做分析，但要维护两套系统，中间还要搭ETL管道。这套方案我跑了两周就烦了，每天盯着数据同步有没有断，实在不是长久之计。

我测的那款自研内核的数据库，实现了行存和列存的混合引擎。OLTP请求走行存，OLAP请求走列存，数据在两个引擎间自动同步，不需要额外ETL工具。后来我在项目里用KingbaseES，发现它的多模引擎也是这个思路。

不过多模引擎也有代价。行存和列存之间的同步需要时间，在极端实时性要求的场景下可能不够用。另外，两个引擎之间的查询优化器要能正确路由请求，这本身就是技术难题。优化器需要判断一条SQL到底走行存还是列存，判断依据是查询的特征：是否涉及聚合、是否只读少数列、是否需要走索引。判断错了，性能反而不如单一引擎。我在测试中就遇到过，一条带WHERE的OLTP查询被错误路由到了列存引擎，延迟比行存高了三倍。

三款国产数据库和MySQL内核架构对比

下面把我实际测试的四款数据库，从内核层面做个直观对比。

从对比可以看出，自研内核方案在复杂查询上有明显优势，但兼容性和生态成熟度需要额外验证。这也是我在实际选型中重点权衡的地方。

SQL优化器为什么是分水岭，统计信息和代价模型怎么影响执行计划

优化器决定了一条SQL怎么执行：用哪个索引，表连接顺序，要不要做并行查询。

MySQL的优化器主要靠统计信息和代价模型选执行计划，估算每个步骤读多少行数据、做多少次IO、消耗多少CPU。大部分情况够用，但复杂查询容易选错。

三款国产数据库的优化器各有特点。

基于开源改写的那款继承了更复杂的成本模型，支持更多执行计划类型，比如Merge Join。两个已排序大表做等值连接时效率不错。

KingbaseES就是我测的自研内核那款。它在连接顺序搜索上做了定制，我实测过一个八表关联查询，MySQL用了12秒，KES只要3秒多。它的优化器在多表连接上用了动态规划加启发式剪枝的混合策略，表少时穷举搜索，表多时智能剪枝但不丢优。复杂查询场景下，这个策略的优势确实能看出来。

但优化器不是万能的，统计信息过时了就全白搭。

我踩过一个坑。一条简单的COUNT查询，MySQL选了全表扫描，国产库却走了索引然后回表。我当时坚信走索引应该更快，毕竟索引就是用来加速查询的嘛。结果反而慢了十倍。排查了半天才发现是统计信息过期了——这个表上周刚导入了一批新数据，但统计信息还是上个月的。优化器基于过时的数据做判断，选错了执行计划。

手动执行ANALYZE TABLE更新后恢复正常。

-- 查看统计信息是否过期
SHOW TABLE STATUS LIKE 'orders';

-- 强制更新统计信息
ANALYZE TABLE orders;

这个教训让我记住：优化器的判断依赖准确的统计信息。大表批量变更后一定要手动触发更新。不同数据库的统计信息采集策略有差异，迁移后一定要检查采集频率是否满足业务需求。

生态兼容性是隐形成本，驱动备份ORM怎么逐一验证

换了国产数据库，MySQL那套工具链还能不能用？

我踩过几个坑。三款都号称兼容MySQL协议，实际测试下来差异很大。

有一款的JDBC驱动不支持LOAD DATA LOCAL INFILE，数据导入方式得换。后来我测KES的时候，发现它官方提供了MySQL兼容模式的JDBC驱动，大部分场景可以直接替换，省了不少事。

用MyBatis的项目调整不多，因为SQL是手写的。用Hibernate的项目就麻烦了，分页语法、批量插入、自增主键获取方式都得改。

xtrabackup不通用，各家备份工具参差不齐。KES自带备份工具，支持全量和增量，不过从MySQL体系换过来需要重新熟悉操作流程。我在测试环境恢复500G数据，花了将近两个小时，就是因为第一次用不熟悉新工具的恢复流程。

业务SQL实测结果如何，三款国产数据库和MySQL的真实差距

我搭了个模拟订单系统，十张表五百万条数据，跑了五十条核心业务SQL。

-- 订单统计查询（八表关联）
SELECT c.customer_name, o.order_id,
       SUM(oi.quantity * oi.unit_price) AS total_amount
FROM orders o
JOIN customers c ON o.customer_id = c.id
JOIN order_items oi ON o.id = oi.order_id
JOIN products p ON oi.product_id = p.id
JOIN categories cat ON p.category_id = cat.id
JOIN warehouses w ON oi.warehouse_id = w.id
JOIN shipping s ON o.shipping_id = s.id
JOIN payments pay ON o.payment_id = pay.id
WHERE o.create_time >= '2025-01-01'
GROUP BY c.customer_name, o.order_id
ORDER BY total_amount DESC
LIMIT 100;

这条查询MySQL要12秒。KES只要3秒多。简单查询上差距不大，OLTP场景差异很小。

迁移成本也得考虑。KES大部分MySQL语法都兼容，不过从MySQL换到任何非MySQL体系的数据库，GROUP BY严格模式都需要检查。测试时有两条SQL做了微调，改一下就行。但如果业务SQL多，提前做兼容性评估很重要。

我一度想选开源改写那款，因为兼容性好，团队上手快。后来想明白，兼容性好只是降低了迁移成本，不等于长期用起来更好。内核能力才是决定上限的东西。

信创数据库选型怎么做，我的四条实用建议

折腾了一个多月，我总结了几条选型建议。

第一，不要只看benchmark数据。跑分是厂商优化过的场景，不代表你的业务也快。用你自己的核心SQL，在你自己的数据量上跑。

第二，先测兼容性再测性能。你的应用有多少SQL需要改？ORM框架兼容吗？备份工具能用吗？监控体系能接吗？这些问题比快不快更重要。

第三，统计信息一定要及时更新。国产数据库的优化器依赖统计信息，大表数据变更后手动触发ANALYZE TABLE，别等查询变慢了才想起来。

第四，考虑团队的学习成本和厂商的生态。团队熟悉MySQL就选基于MySQL改写的方案，迁移成本最低。需要OLTP和OLAP混合负载就选带多模引擎的方案。同时要看厂商的路线图、社区活跃度和落地案例。国产数据库还在快速迭代中，不能用成熟产品的标准要求。

国产数据库选型决策框架，什么场景选什么方案

下面是我整理的选型参考。

避坑清单

第一，别只看性能跑分。跑分是厂商精心挑选的场景，不代表你的业务。用自己的核心SQL跑一遍，看执行计划对不对，有没有走错索引。我那次就是差点被跑分骗了，三家跑分差不多，业务SQL一跑差距就出来了。

第二，统计信息必须及时更新。大批量数据变更后手动执行ANALYZE TABLE。有些国产数据库的统计信息采集频率和MySQL不一样，我那次就是数据导入后忘了更新，一条COUNT查询慢了十倍，查了半天才发现是统计信息过期。

第三，生态兼容性是隐形成本，要提前评估。驱动、ORM、备份工具、监控体系每个环节都可能踩坑。选型之前拿一套真实的业务模块做完整验证，别上线了才发现备份工具用不了。我恢复500G数据花了两个小时，就是因为不熟悉新的备份流程。

第四，别拿成熟产品的标准要求还在迭代的产品。选型时看厂商的路线图和落地案例，不能只看当前版本的功能。

信创选型这件事，让我从"会用数据库"升级到了"理解为什么这么设计"。

以前觉得MySQL就是全部。现在才知道，每种内核都有自己的取舍，没有万能的方案。

后来我选了KingbaseES。原因有三个：自研内核有技术深度，多模引擎能同时跑OLTP和OLAP，政企场景的落地案例多。KES的优化器在复杂查询上表现不错，安全审计能力也是我比较看重的。信创生态里，金仓的社区活跃度和文档质量都靠前。迁移前做好SQL兼容性评估就行，大部分改改就能跑。

你在国产数据库选型时踩过哪些坑？欢迎一起聊聊。

我是数据库小学妹，咱们下篇见 👋