干国产数据库选型顾问这几年我接到最多的求助消息就是“我们老大丢过来四个字国产数据库然后让一周内给方案怎么办”国内叫得上名字的数据库至少有二三十款每家的宣传手册都写着“高可用、高性能、平滑迁移”但真正POC跑下来配置参数、SQL习惯、运维方式南辕北辙根本不是选个产品那么简单。这篇就是给被国产数据库选型困扰的人写的无论是做架构决策的技术负责人还是被拉去写评估报告的开发、DBA照着“4大技术路线、3大评估维度、1张速查对照表”这个框架走可以在两三天内把选型从一团乱麻梳理成一份可以评审的文档。1. 四大技术路线先把盘子分清楚国内数据库看起来百花齐放但剥开外壳看内核绝大部分都能归类到四条技术路线里。路线分清楚后初始候选清单基本就砍掉了一半。1.1 路线一Oracle兼容型集中式数据库这一路线的典型代表是达梦DM8、人大金仓KingbaseES以及部分金融场景里的GaussDB集中式版本。它们的设计目标非常明确——承接从Oracle迁移过来的存量业务让老DBA能沿用大量既有经验。达梦的SQL语法、PL/SQL写法、包机制处处能看到Oracle的影子金仓本身脱胎于PostgreSQL内核又在兼容层上做了大量Oracle化改造。这类产品适合什么场景存量Oracle系统要替换业务代码又不想大改团队里还有一批熟悉Oracle的老兵。实测下来常规SQL、存储过程、触发器、序列的迁移兼容度能做到七八成以上这是最吸引人的地方。但我也说句实话Oracle兼容不是“免费午餐”。越是深度依赖Oracle特性的系统越容易在细节上翻车物化视图的刷新机制、分区索引的细微差异、PL/SQL包里嵌套依赖的顺序都可能成为隐藏雷点。某些系统看似迁完了一到月底批量任务就跑不动最后还得花大量精力做SQL改写。选这条路线等于把未来和这家数据库的兼容层质量绑定在一起POC时要专门针对“高级特性用量”做一次摸底。1.2 路线二MySQL/PG生态衍生型这个阵营最庞大openGauss脱胎于PostgreSQL阿里PolarDB同时覆盖MySQL和PG两条兼容链路腾讯TDSQL for MySQL、万里GreatSQL、以及OceanBase的MySQL兼容模式都算广义上的MySQL生态一员。这类数据库的最大优势是开发人员零门槛上手MySQL/PG的语法、驱动、ORM框架几乎直接可用招聘成本低资料多出了问题能搜到大量社区经验。MySQL/PG衍生型其实是绝大多数互联网新建业务的默认选择。它的适用边界也很清楚如果你要做的是交易型系统OLTP数据量在单机或小集群能扛住的范围内这个路线基本不会踩大坑。选择时重点看三件事兼容的是MySQL 5.7还是8.0对InnoDB特有行为比如间隙锁、自增锁方式支持到什么程度主从复制和高可用方案的成熟度如何。值得提醒的是很多人误以为“兼容MySQL”就等于“MySQL能跑的这里也能跑”。真实情况是存储引擎、索引实现、事务隔离级别的细节差异会让某些在MySQL上运行良好的业务在高并发下出现意想不到的问题。选这个路线最好先用真实业务做一轮压测而不是只看宣传页上的“100%兼容”。1.3 路线三原生分布式架构代表产品是TiDB和OceanBase腾讯TDSQL的分布式形态也归入这一类。这类数据库生来就是分布式的数据自动打散到多个节点支持水平横向扩展事务和强一致性由底层共识协议Raft、Paxos保障高可用能力是设计时就内建的而不是靠外部中间件拼出来。原生分布式适合数据量已经大到单机扛不住、或者未来几年有明确爆发式增长预期的业务。比如交易流水一天几千万条、总量超过几十TB再比如大促时流量翻几十倍这类场景下分布式几乎是必须的。TiDB的MVCC存储与自动分片、OceanBase的Paxos多副本机制都能给出非常漂亮的扩展性和可用性指标。但分布式是有代价的首先是资源开销同样的业务量分布式集群攒的服务器往往比集中式多出一截其次是运维复杂度集群扩容、Region调度、热点问题调优需要专门的团队和知识储备最后是跨节点事务性能分布式的强一致事务和单机性能相比天然有差距需要用合理的分片策略弥补。如果业务没过几百GB硬上分布式只会给自己找麻烦。1.4 路线四分析型OLAP数据库最后一条路线是面向数据分析场景的产品包括Apache Doris、StarRocks、阿里AnalyticDB、华为GaussDB(DWS)以及ClickHouse及其国内发行版在日志和明细分析场景中占据的一席之地。这里需要点醒很多人OLAP数据库不是用来替代OLTP的而是承接业务库之外的报表、统计、多维分析、实时数仓场景。它们普遍使用列式存储、向量化执行引擎和并行查询框架跑复杂聚合查询时性能可以甩开传统行存库几条街。举个直观的例子一张上亿行的订单表同样的分组汇总SQL在一个OLTP库里可能要跑几十秒在Doris或StarRocks里往往一两秒就出结果。选型时看两个核心点一是数据导入链路顺不顺能不能方便地接入MySQL、Kafka、文件数据源二是查询场景和产品特性是否匹配比如StarRocks和Doris在明细查询、预聚合模型上各有侧重。同时也要明确很多OLAP产品的事务能力弱、更新删除能力有限想把它当作主业务库使用基本属于拿错工具办错事。四条路线之间其实在逐步融合OceanBase既做OLTP也在加强分析能力StarRocks通过主键模型增强了实时更新能力这不影响选型逻辑。第一步永远是先确定业务主场景再按路线圈出候选池。2. 三大评估维度选型到底看什么路线划分只是第一步真正决定选谁要看从哪些维度去打分评估。我把这些年做选型评审的经验浓缩成三个维度业务匹配度、生态兼容性、总拥有成本。2.1 业务匹配度先别聊技术先聊业务评估选型的第一件事不是比较哪家数据库参数更好看而是把业务需求量化成一组“硬指标”。这里有三组数字必须搞清楚峰值场景的QPS/TPS是多少数据总量和增长趋势是什么业务对RPO/RTO的容忍底线是多少。举个例子如果系统是核心账务系统RTO以分钟计那么单机的弱高可用方案基本不达标如果只是内部管理系统的报表库就没必要为极高可用性付出几倍的硬件成本。业务匹配度还要看读写比例。交易系统写多读多事务复杂适合事务能力强、索引支持完善的关系型数据库报表分析系统读多写少、查询复杂就适合列存和并行查询能力强的分析型数据库。如果是一个需要实时报表又承担交易的新业务那就得考虑HTAP能力或者接受“OLTP库同步链路OLAP库”这种组合架构。不少团队在需求不清晰时就急着列产品清单结果选出来的数据库和业务完全错配。我的建议是所有业务方和研发负责人先坐下来用半天时间把上面的硬指标、读写比例、未来增长率统一定义清楚再拿着这张纸去聊产品效率会高很多。2.2 生态与兼容性决定团队和迁移的生死第二个维度是生态与兼容性建议从两个层面审视。第一层是SQL和编程接口的兼容度——是兼容MySQL协议还是兼容PG/Oracle协议直接影响现有代码能否低改动迁移。第二层是周边工具的成熟度监控告警、备份恢复、数据同步工具、BI系统连接器以及社区和官方文档的质量。很多团队在选型时只关注数据库本身结果到了迁移阶段发现配套的监控平台不支持、数据同步工具要另外开发、BI报表连不上七七八八花掉的时间和钱比数据库许可费还多。所以我一直建议评估生态时直接让团队把“从写代码到上线运维”的完整链路走一遍开发、DBA、运维各自评审自己那一环比任何权威测评都更有说服力。特别要提醒一点数据库的“兼容”分很多层级。协议兼容意味着客户端能连上语法兼容意味着常用SQL能跑行为兼容意味着事务隔离级别、锁机制、异常语义都一致。很多产品只在第一层做到了后面两层需要逐项验证。2.3 总拥有成本TCO看得见的钱和看不见的钱第三个维度是成本也是最容易算错的一笔账。看得见的成本包括软件授权费用商用数据库或云数据库实例以及服务器、存储等硬件支出。看不见的成本至少有三块一是迁移改造成本存储过程改写、SQL调优、数据校验往往占整个项目的大头二是运维人力分布式数据库的专职DBA和集中式数据库的DBA薪资和人数完全不一样三是演进成本版本升级、扩容缩容、故障演练云原生和本地部署的体验差异巨大。这里分享一个我常用的估算方法把未来三年的人员成本、迁移工时、硬件增长、软件费用都列出来用同一个公式折算成年度总成本再对比。你会发现有些免费开源产品的TCO反而不低因为运维和迁移的隐性成本拖得很重而有些商用产品虽然授权贵但迁移工具成熟、有原厂支持整体反而划算。2.4 三维度怎么落地成打分表三维度说完了实际操作时建议把它们拆成可打分的细项。我的经验值是业务匹配度占40%生态兼容性占35%总拥有成本占25%具体权重可以按公司战略调整但思路是一样的每维度下设3到5个细项每项打分1到5分乘以权重后求和。比如“业务匹配度”下的细项可以是峰值TPS满足度、数据增长支持度、容灾目标满足度“生态兼容性”下是SQL兼容度、工具链成熟度、团队学习成本“成本”下是三年TCO、迁移改造量、原厂支持水平。打分表最好让开发、DBA、运维、架构leader各打一轮四份分数取加权平均再组织一次复议。这样虽然多花一两天但能有效避免选型被某一个团队的偏好绑架。做完打分再结合下一章的对照表就能将二三十个候选收敛到两三个进入POC实测阶段。3. 一张对照表主流国产数据库核心速览下面这张表是这篇文章里我最想让大家保存的部分。我挑了市面上最常见、在真实项目里出现频率最高的一批产品按技术路线、兼容SQL、最佳适用场景和注意事项四列做了整理。需要说明的是产品能力迭代很快表格反映的是我截至目前的实践经验正式选型时务必以最新版本的实际测试结果为准。数据库技术路线兼容SQL最佳适用场景注意事项OceanBase原生分布式MySQL/部分Oracle金融核心交易、超大并发场景资源开销较高对运维团队要求高TiDB原生分布式MySQL互联网业务、海量数据水平扩展跨节点事务和热点读写需专门调优TDSQL云原生分布式MySQL腾讯云生态、分布式事务型业务私有化和云形态能力差异较大openGaussPG生态衍生PostgreSQL/部分Oracle政企通用OLTP、新兴业务社区活跃度和版本演进节奏要持续关注PolarDBMySQL/PG衍生云原生MySQL/PG阿里云生态、通用OLTP云上体验好私有化能力看具体版本达梦DM8Oracle兼容集中式Oracle为主Oracle存量替换、传统项目深度Oracle特性兼容需逐项验证人大金仓PG衍生Oracle兼容Oracle/PG政务、金融存量替换迁移工具链稳定性需要在真实数据量下实测Apache Doris分析型OLAPMySQL协议实时报表、多维分析不适合当OLTP主库使用StarRocks分析型OLAPMySQL协议实时数仓、大宽表分析主键模型有增强但事务能力仍有限GaussDB(DWS)分析型MPPPostgreSQL/部分Oracle数据仓库、大数据分析和GaussDB的OLTP集中式是两套产品别混淆AnalyticDB云上分析型MySQL等云上实时分析、数据仓库与云环境绑定较深跨云迁移成本高ClickHouse及其发行版分析型OLAP部分标准SQL日志、时序、海量明细数据高并发点查和更新删除能力较弱这张表有个使用误区我得专门强调看到“兼容MySQL”就认为“MySQL线上业务可以直接迁移过去”。这个“兼容”更多停留在协议和SQL层面存储过程、分区表、字符集细节、高可用配置都可能出现差异。所以对照表只能用来圈定初选范围正式选型必须落到POC实测千万别省这一步。4. 实操避坑实录我在POC和迁移现场踩过的坑选型不是选最牛的是选最容易落地、最容易活得久的。这个理解是我在几次POC和迁移项目中用真金白银换来的下面把这些坑里最典型的几个写出来给后来人做个参考。4.1 POC测试别只跑TPC-C和TPC-H很多团队做POC上来就用SysBench、TPC-C、TPC-H这类基准测试跑分跑完就觉得心里有底了。我的建议是基准测试只能作为参考线真正要跑的是和业务最接近的混合负载。实操时我一般会这么做先把生产环境的真实SQL抓出来脱敏后整理成压测脚本同时按业务比例混入事务、查询、批量操作三类负载再模拟峰值并发。真实业务POC还有两个必测项一个是长稳测试至少连续跑72小时观察内存泄漏、连接池耗尽、慢查询曲线是否平稳另一个是故障演练直接在集群里杀掉一个节点观察RTO和RPO是否符合预期。很多数据库产品短跑成绩很好一长跑、一断电就露馅。记住一句话POC的结论不能写在性能最优的报告里而要写在故障恢复的记录里。4.2 迁移绕不开的四个坑迁移是选型后最先遇到的实战常见坑至少有四个数据类型映射、存储过程和触发器改写、序列与自增主键行为、字符集与排序规则差异。以Oracle迁移到MySQL兼容模式为例NUMBER(10)到int、BLOB/CLOB到大字段处理、空串和NULL的差异这些细节如果没在迁移方案里写清楚后面一定会要求返工。我的做法是迁移前先做一轮“方言体检”把源库所有的建表语句、存储过程、触发器和SQL日志拉出来过一遍兼容性分析工具或人工分类把改动量分高、中、低三档统计然后根据结果决定是降低改造量还是调整数据库选型。这个体检一定要在选型完成前做而不是确定产品后再做否则容易陷入“定都定了硬着头皮迁”的被动局面。4.3 高可用方案别想当然很多人习惯性假设“数据库自带高可用”但不同产品的实现差异非常大。比如TiDB基于Raft协议数据多个副本分布在不同节点能自动选主OceanBase基于Paxos多机房部署天然支持容灾切换而传统的MySQL主从方案则需要配合MHA、Orchestrator或云上的高可用组件才能实现自动切换。这部分避坑经验是一定要在POC阶段把“容灾切换演练”当成必做项而且要在业务低峰期做一次真实的强制切换把业务流完整切到备库再切回来。只看RTO数值是没用的切换过程中连接池的失效重连、会话状态丢失、路由层缓存刷新每一项都会影响真实恢复时间。这些东西只有真正演练过才能写进运维手册。4.4 版本升级与长期演进方向选型还决定了未来几年你的数据库会怎么走。开源和商用数据库的版本升级策略差别很大开源社区版需要自己跟踪主线版本、设计滚动升级方案商用产品有原厂护航但升级窗口、方案评审的流程一般也更重。建议在选型时就把“大版本升级路径、小版本补丁策略、是否支持滚动升级”这三件事列成问题直接去问原厂或社区。另外要关注产品路线图是否稳定。我是吃过一次亏的——当年一个项目基于某个开源分支定制结果上游社区重组、版本断更只能长期锁定在旧版本。后来我养成了一个习惯选型前查社区活跃度、查最近一年的版本发版频率和Issue回复速度把它当成数据库生态健康度的硬指标。技术债可以慢慢还但一个停止演进的产品会让整个团队的投入全部沉没。最后说几点我个人的体会。国产数据库选型这件事本质上不只是技术选型也是团队选型、组织选型。同一个数据库在不同团队手里能做成完全不同的结局。我的建议是别只迷信别人的评测和榜单也别被厂商的宣讲带节奏把业务搞清楚、把团队底牌摸清、把三年后的成本估算清楚这三件事做完答案自然就浮出水面了。希望这篇避坑指南能帮你在国产数据库这道题上少走几个弯路少花几笔冤枉钱。