国产数据库选型与迁移实战：六家主流产品对比与踩坑指南

"国产数据库这桌饭，到现在还能六家同桌吃"——这话不是我说的，是我前几天跟一个老朋友吃饭时他感慨出来的。他在某大型国企里干了十几年DBA，Oracle、DB2、SQL Server都摸过，这两年眼看着国产数据库从"能不能用"到"好不好用"，从几家独大到十几家混战，现在能稳定坐上主桌的，数来数去还是六家。这话糙理不糙，背后其实是国内数据库市场这几年的真实演变。我听完挺有感触，干脆把我自己这两年在国产数据库上做的选型测试、迁移踩坑、性能调优的经验梳理一遍，给还在观望、正准备上车的朋友做个参考。

这篇文章我会从市场格局、技术流派、选型实践、迁移落地、运维调优几个层面展开，结合我实际干过的活来讲。不管你是要做技术选型的架构师，还是整天跟SQL打交道的DBA，或者是想了解国产数据库现状的研发，应该都能在里面找到点有用的东西。

1. 这桌饭是怎么坐齐的——国产数据库的牌桌格局

1.1 从"老四家"到"六家同桌"的演进

先说结论。现在大家公认坐上主桌的六家，大致是：达梦、人大金仓、南大通用、神通、OceanBase、TiDB，再算上华为GaussDB和openGauss体系，说六家其实还是保守了，实际上细分赛道里能打的远不止这些。但如果按市场份额、行业覆盖、生态完整度来排，这六位确实是目前最能打的。

我对国产数据库的记忆，最早可以追溯到大学时候。那时候教材里讲到国产数据库，翻来覆去就是"老四家"——达梦、金仓、神通、南大通用。这四家有个共同特点：都是从高校或科研院所孵化出来的，走了二十多年，一直不温不火。它们的打法高度相似，典型的老一派玩法，靠项目制生存，每一个单子都要定制化开发，每一个客户都要派工程师驻场。这种模式在早期确实撑起了国产数据库的一片天，但也埋下了隐患：产品迭代慢，社区生态几乎为零，文档稀烂，开发者想用都找不到门路。

转折点大概出现在2015年前后。那一年OceanBase在支付宝的核心交易系统里扛住了双11的流量，后来又在TPC-C测试里拿了第一，一下子把"国产分布式数据库"这个名号打响了。TiDB也差不多在那个阶段冒出来，走的是开源路线，直接把文档、社区、生态三板斧做齐了。这俩"新势力"给国产数据库带来的冲击是巨大的——原来数据库还能这么做，原来国产数据库也能有极客味。

再往后，华为GaussDB和openGauss入局，阿里PolarDB、腾讯TDSQL也跟着发力，市场一下子热闹起来。到现在这个时间点，传统四大、新势力、云厂商三方势力同台竞技，反而形成了一种微妙的平衡——谁也吃不掉谁，但谁也不敢躺着不动。

1.2 为什么坐住的偏偏是这几位

我这两年走访了不少客户，也跟数据库厂商的售前、研发聊过，总结下来，能在牌桌上坐稳的，基本都满足了三个条件。

第一，有真金白银堆出来的核心场景。OceanBase扛过双11，TiDB在金融、互联网有大量生产实践，达梦在党政、电力、军工这些行业里深耕多年。这些场景不是说你有钱就能买的——场景倒逼产品打磨，数据库这种基础软件，没有真实流量反复摩擦，光靠写代码测试是测不出问题的。

第二，生态不是喊口号喊出来的。TiDB走开源路线，文档、社区、工具链都齐了，开发者遇到问题能搜到答案，能提issue，能自己改代码。达梦和金仓这几年也学聪明了，开始做兼容层，让Oracle的DBA能平滑上手。生态这东西，看起来虚，实际上直接决定了一个数据库的"上手成本"，而上手成本又决定了开发者和DBA愿不愿意用。

第三，商业模式跑得通。这六家里，有的靠授权收费，有的靠云服务收费，有的靠开源+企业版双轨制。不管哪种模式，至少证明了一件事：这个产品能养活自己，能持续投入研发，而不是靠补贴或者项目款吊命。

1.3 牌桌之外的细分选手

除了这六家，细分赛道里还有一批值得关注的选手。比如做时序数据库的TDengine，在物联网、工业监控、金融行情这类时序数据场景里做得相当不错。我这半年在好几个工业互联网项目里都用了TDengine，它的taos_stmt_prepare这种预处理接口配合C++绑定写入，实测写入性能非常可观。再比如向量数据库，随着大模型应用落地，Milvus、Weaviate这些专门给embedding数据服务的产品也火起来了。加上这几年流行的SQLite系、单文件数据库、嵌入式数据库，整个国产数据库生态已经呈金字塔形分布——底层是大量工具型、嵌入式产品，中间是通用关系型数据库，顶层是分布式、云原生数据库。

我的判断是，未来两三年牌桌还会洗牌，但洗掉的多半是那些没有核心场景、没有社区、没有明确技术路线的产品。六家里可能有人掉队，细分赛道里也可能杀出黑马，但大格局短时间内不会有根本性变化。

2. 六家各有各的拿手菜——技术路线与核心差异

2.1 集中式和分布式，不是一个物种

先说最容易被忽略但其实最关键的一个差异：这六家在架构上是分两大派的。达梦、金仓、南大通用基本走的是"集中式+共享存储"路线，架构上跟Oracle、DB2高度相似，主备复制、RAC集群、高可用切换，这些概念对老DBA来说非常亲切。OceanBase、TiDB走的是"分布式+水平扩展"路线，数据打散到多台机器上，通过一致性协议保证可靠性，扩容就是加节点的事情。

这两个路线没有绝对的好坏，完全看场景。如果你的业务形态是"一个核心库，读写都打在上面，事务要求极高"，集中式反而是一个更稳妥、更可控的选择。如果你的业务是"数据量会爆炸式增长，并发量高，需要弹性伸缩"，那集中式在扩容上的成本会让你非常难受。

我见过一个真实的案例。某个省级政务平台，一开始用的集中式架构，跑了几年数据量上去了，单库超过5TB，备份一次要四五个小时，主从切换还会丢数据。后来迁到分布式数据库上，按地市分片打了四个节点，备份时间缩短到40分钟，查询性能反而翻了一倍。这个案例没有什么高深的技巧，纯粹是架构选型匹配了业务形态。

2.2 兼容协议决定迁移成本

选国产库，最先要看的就是兼容协议。所谓"兼容"，不是说你拿Navicat能连上就算兼容，而是你的应用代码、SQL语法、存储过程、甚至DBA的运维习惯，能不能以最低成本平移过来。这是国产数据库最核心的竞争力之一，也是所有迁移项目里最容易踩坑的地方。

目前市场上主要分两派：兼容Oracle语法的和兼容MySQL语法的。达梦、金仓、神通都提供Oracle兼容模式，存储过程、包、触发器这些Oracle特有的东西，尽量做到语法级兼容。OceanBase和TiDB则走MySQL协议兼容路线，MySQL的程序连上来几乎不用改。GaussDB比较特殊，它有openGauss和MySQL两个版本线，分别适配不同的Oracle和MySQL迁移需求。

我自己实测下来的感受是：兼容Oracle的那批，在存储过程、包这种重度PL/SQL逻辑上，能做到八九成的平滑迁移，但总会有一些边缘语法、内置函数行为不一致，需要人工改。兼容MySQL的那批，因为MySQL本身的语法相对简单，所以迁移会顺畅很多，但事务隔离级别、死锁处理这些底层行为还是有细微差别，不能完全想当然。

2.3 云原生与私有化，姿态决定路线

除了架构和协议，还有一个隐形维度是部署姿态。有的产品主打私有化部署，你买一套软件，装在自己的机房或者政务云里，数据完全自控，适合对合规要求极高的政企客户。有的产品主打云原生，开箱即用，按量付费，适合互联网公司和中小企业。有的产品则两条腿走路，开源一个社区版做生态，商业版卖服务和支持。

这个选择的本质是：你愿不愿意把数据库的运维交给别人。如果你们公司没有专职DBA，上云托管数据库服务其实是最省心的选择。如果数据敏感度高、又恰好有自己的运维团队，那私有化部署更可控。用得上的工具也不一样：托管数据库服务一般自带监控告警、自动备份、一键扩容，私有化部署则需要自己搭Prometheus+Grafana这一套，或者用dbx这类数据库管理工具做日常巡检。

2.4 工具链的成熟度也在拉齐

早期用国产数据库最难受的是工具链跟不上。Navicat连不上、IDE没有插件、备份恢复靠命令行、可视化运维平台几乎没有。这两年情况好了很多。dbx数据库工具这类通用管理客户端，已经能兼容大部分主流数据库，包括达梦、OceanBase、TiDB这些国产库都能连上。Navicat从16版本开始也逐步支持国产数据库，DBeaver社区版对TiDB、openGauss也有不错的支持。

但对DBA来说，工具链只是冰山一角。真正重要的是性能监控、慢SQL分析、死锁检测、备份恢复这些能力有没有做好。这方面国产库的差距还是存在的，尤其是那些没有图形化运维平台的产品，出了问题基本要靠手工排查。所以我一直强调：选型的时候，把工具链的成熟度作为一个硬指标，而不是软指标。一个没有好工具的系统，运维成本和故障恢复时间都会成倍增加。

3. 谁适合上桌——数据库选型的实操心法

3.1 选型第一步：搞清业务画像

我见过太多团队选数据库，上来就看性能测试报告，比谁跑分高、比谁并发强，结果选完上线就后悔。选型的第一步，永远是搞清楚业务的真实画像。这个库未来三年大概会到什么数据量？读写比例是多少？峰值QPS和TPS是多少？有没有强事务要求？有没有复杂的关联查询？需不需要全文检索、地理空间、时序数据这类特殊能力？

把这些问题的答案写下来，你会发现很多数据库根本不在备选范围里。比如你的业务是IOT设备上报数据，那就老老实实看TDengine这类时序库，别去折腾通用关系型数据库。你的业务是图关系分析，那就看图数据库。你的业务是标准OLTP交易系统，那再从达梦、OceanBase、TiDB、MySQL这些里面挑。

3.2 评估六要素：性能只是及格线

我这几年做选型评估，固定用六个维度打分：性能与稳定性、兼容性、生态与文档、运维便捷性、社区活跃度、商业支持。每个维度按10分制打分，最后加权平均。光看性能是最容易踩坑的，因为你测出来的好性能，未必能在生产环境里复现。稳定性更是选型的底线，一个数据库偶尔慢可以接受，但让你丢数据或者频繁宕机，性能再高也不能要。

兼容性我用一套自己总结的"迁移冒烟测试"来评估：把老库里最复杂的50条SQL、10个存储过程、5个触发器、3个调度任务，原样搬到新库里跑一遍，看能过多少，报错哪些，需要改哪些。这个测试能直观反映迁移成本，比任何PPT都靠谱。生态与文档就看一件事：当你遇到报错的时候，能不能在半小时内搜到解决方案。搜不到的话，这个数据库对你的团队来说就是一个黑盒，出了问题只能等原厂。

3.3 行业案例：银行、政务、互联网怎么选

不同行业的选型逻辑确实不一样。金融行业我接触最多，核心交易系统对一致性、可靠性要求极高，所以大部分银行都选了达梦或OceanBase这类经过大量金融场景验证的产品。政务行业更看重合规和信创协同，人大金仓和达梦的渗透率很高，因为它们跟国产操作系统、国产芯片的适配做得最早也最完整。互联网公司则更偏好TiDB这类开源分布式数据库，一方面技术栈更开放，另一方面招聘成本和上手成本都更低。

我印象最深的是一家地方城商行的案例。他们的核心系统原来跑在IBM小型机加Oracle上，每年维保费用高得吓人。后来经过大半年评估，选了OceanBase做核心交易库，达梦做报表分析库，一个小型机都没留，全部换成x86服务器。上线到现在两年了，没有出过一次数据丢失事故，故障切换时间从原来的分钟级降到了秒级。这个案例说明一件事：国产数据库已经过了"能不能用"的阶段，现在比的是"谁更懂业务、谁落地更稳"。

3.4 你们团队的能力模型也要纳入评估

这一点很少有人提，但我认为它其实决定了迁移的成败。你们的DBA懂Oracle还是懂MySQL？你们研发团队写SQL的习惯是哪种风格？你们有没有专职的中间件和运维开发人员？如果团队全是Oracle背景的DBA，你选一个MySQL协议的数据库，那他们就要从头学起，迁移期间的效率会大打折扣。反过来，如果团队本身就是MySQL技术栈，硬上Oracle兼容模式的国产库，同样会水土不服。

我的建议是，选型不是技术负责人一个人拍脑袋的事，把团队的数据库DBA、核心应用开发、运维负责人拉到一个会议室里，至少讨论三轮再定。第一轮摆事实，各自列需求和顾虑；第二轮做技术验证，把关键场景跑一遍；第三轮看成本和投入产出比，拿出一个全团队都认的结论。

4. 从老库到国产库——迁移路上的那些坑

4.1 迁移不是"搬数据"，而是"重构应用"

很多团队对迁移的理解就是：把老库的数据导出来，再导进新库，然后改一下连接串，完事。这种想法非常危险。数据库迁移的本质是应用与数据访问方式的一次重构，你写了几年的SQL、存储过程、定时任务、ORM映射，全都可能因为底层数据库的行为差异而出问题。

我在一个MySQL向TiDB迁移的项目里，遇到过最典型的例子：老系统里有一条SQL，用了MySQL特有的分页写法limit 100000, 20，在MySQL里跑得挺快，但到了TiDB上，相同写法直接把一个节点拖垮了。原因很简单，TiDB的分布式架构处理深分页的方式跟单机MySQL完全不同，大偏移量的limit在分布式环境下会产生恐怖的扫描开销。最后我们改了SQL，用where id > ? order by id limit 20的方式做游标分页，性能才恢复正常。

这个案例说明，迁移之前一定要做充分的代码审计。把所有SQL捞出来，逐条看有没有用数据库特有的语法特性、函数、数据类型。MySQL的group_concat、Oracle的connect by、SQL Server的top n等特性，在新库上要么不支持，要么行为不同。提前把这些雷排掉，迁移过程会顺滑很多。

4.2 数据迁移工具与双写方案

数据迁移工具方面，我的经验是：别迷信原厂提供的一键迁移工具，尤其是跨品牌迁移。原厂工具往往只覆盖数据类型的映射，对代码、存储过程、触发器、序列、视图这些"非数据类"对象支持得很弱。我的标准操作是把迁移拆成两条线并行：一条用原厂工具搬数据，搬完做一致性校验；另一条用我自己写的对象迁移脚本，把存储过程、触发器、定时任务、用户权限这些手动重建。

如果是核心系统，强烈建议做"双写"过渡。所谓双写，就是新旧数据库同时运行，应用层把写操作同时发送到两边，读操作先走老库，等两边数据一致稳定后再切到新库。这个过程对应用改造的要求比较高，但能最大程度降低迁移风险。我见过不少项目图省事直接切库，结果上线就像开盲盒，问题全在高峰期冒出来，最后只能整体回滚。

4.3 迁移过程中最常见的四类报错

第一类是数据类型映射错误。Oracle的NUMBER不带精度和刻度，迁移到达梦或分布式库后可能被映射成BIGINT或者DECIMAL，精度变了，应用传参就会报错。第二类是SQL语法兼容问题，比如Oracle的(+)外连接语法、MySQL的ON DUPLICATE KEY UPDATE，在新库上可能不支持或者行为有差异。第三类是事务隔离级别问题，Oracle默认是读已提交，MySQL默认是可重复读，迁移后不显式设置隔离级别，可能在并发场景下出现幻读或不可重复读。第四类是序列和自增主键的行为差异，Oracle的序列是独立的数据库对象，MySQL的自增是表属性，迁移后如果在同一事务里插入多张表并依赖自增ID的顺序，可能会出现ID错乱。

这些问题没有统一的解决办法，只能靠充分的前期测试去提前暴露。我的习惯是：迁移前准备一套完整的回归测试脚本，覆盖增删改查、事务提交回滚、存储过程执行、触发器触发、分页查询、批量导入导出这些常规场景，每迁完一张表就自动跑一遍，出了错第一时间修，不要等全部迁完再测。

4.4 常见问题速查表

5. 国产数据库的运维与调优——土办法和硬功夫

5.1 死锁问题：一个从Oracle到国产库必踩的坑

死锁是所有DBA绕不开的话题，国产数据库上也不例外，甚至因为很多国产库在并发控制实现上和传统商业数据库有差异，死锁问题反而更突出。我排查过的一个典型案例：一个订单系统在并发高峰期频繁报死锁，应用日志里全是Deadlock found。一开始我们以为是SQL写得有问题，后来拉出来死锁日志一看，发现是两张表在事务里更新的顺序不一致导致的。

两个并发事务，一个先更新订单表再更新库存表，另一个先更新库存表再更新订单表，这就形成了经典的循环等待。在Oracle上因为有行级锁和更精细的并发控制，这个问题的触发概率低一些，但国产库的默认隔离级别和锁粒度设置不同，触发概率就高了很多。解决方法是统一所有事务里表的访问顺序，并且尽量缩短事务执行时间，减少锁持有的时长。另外，排查死锁的时候，先看数据库自己的死锁日志，再去看应用日志，很多国产库都内置了死锁检测机制，比应用层的超时报告准确得多。

5.2 连接池的配置不能照抄MySQL

连接池配置是另一个高频踩坑点。很多团队从MySQL迁过来，连接池参数直接照搬，结果上线就遇到连接数打满、连接池耗尽的问题。原因是部分国产分布式数据库的连接管理机制跟MySQL的单机模型不一样，每个连接背后可能要占用更多内存和CPU资源，连接数开得太大反而会因为资源竞争拖垮节点。

我的建议是：新库上线时把连接池的初始大小调小一些，比如原来MySQL配50个初始连接，新库先配10到20个，观察运行情况再逐步往上加。同时，一定要设置合理的连接空闲回收时间，别让池子里堆满长连接。另外，注意区分连接池的读连接和写连接，读写分离架构下，千万别共用一个连接池。

5.3 监控体系的搭建思路

监控体系是国产数据库运维的关键，也是很多团队忽视的环节。我的标准做法是三层监控：第一层是系统层，用Prometheus采集CPU、内存、磁盘IO、网络带宽这些主机指标；第二层是数据库层，通过数据库自带的性能视图或者API采集活跃会话、锁等待、慢SQL、缓存命中率这些指标；第三层是业务层，在应用里埋点记录每一个数据库操作耗时，把耗时异常的操作关联到SQL和具体业务场景。

这三层缺一不可。系统层能告诉你"机器是不是扛不住了"，数据库层能告诉你"库内部发生了什么"，业务层能告诉你"用户实际感受到了什么"。我见过太多团队只做了第一层，机器指标一切正常，但业务卡死，最后排查半天才发现是某个慢SQL把连接池堵死了。

5.4 备份恢复的"最后一公里"

备份恢复是国产数据库绕不开的话题，也是最容易被低估的环节。很多产品在备份恢复功能上确实比老牌商业库要薄弱，所以我做国产库项目的第一件事，永远是搭好备份恢复的三道防线：全量备份、增量备份、binlog/WAL日志归档，缺一不可。

这里我要特别强调"恢复演练"的重要性。我们做过一次国产库的容灾演练，模拟主节点宕机，结果是：主备切换没问题，数据没丢，但恢复后应用连不上了，因为备节点上的用户权限没有同步过去。这种问题在文档里很难发现，只有在真实演练里才会暴露。做国产库运维，一定要把"定期演练"当成规章制度，而不是可选项。另外，备份文件一定要异地存放，千万别跟数据库放在同一台机器上，否则机房断电或者硬盘损坏，你的备份也跟着没了。

5.5 开发侧配合：参数不只是DBA的事

最后我想说一点可能很多人不同意的话：国产数据库的调优，光靠DBA是不行的，开发团队必须深度参与。传统Oracle年代，DBA是数据库的主宰，开发写好SQL扔给DBA优化就行。但国产数据库尤其是分布式产品，优化逻辑跟集中式差异很大，很多性能问题根子在应用设计上，DBA就算把数据库参数翻个底朝天也没用。

我举一个例子。某项目在OceanBase上跑一个报表系统，有几条SQL怎么调都慢，最后分析执行计划才发现，问题出在表设计上——一个维度表只有几百条数据，却跟一个几亿行的事实表做了join。开发顺手把维度表改成了广播表，SQL从几十秒降到了毫秒级。这就是典型的"调优在应用侧"的场景。所以我的建议是：国产数据库项目里，DBA和开发要形成"联合调优"的机制。DBA负责发现慢SQL、分析执行计划、调整数据库参数；开发要负责改SQL、改表结构、改事务逻辑。谁也不能独善其身，数据库才能真的跑好。

6. 最后聊几句实在话——从这半年踩坑里总结的心得

这半年我手里的国产数据库项目比过去五年加起来还多，踩过的坑、填过的洞、推倒重来的方案，数都数不过来。但恰恰是这些坑让我越来越确信：国产数据库是真的好了，好到我可以放心地把核心业务交给它，而不是像早年那样，总是带着"国产库不能上生产"的刻板印象去看它。国产数据库之间的竞争也越来越像一个健康的生态：有人拼场景，有人拼开源，有人拼服务，最后受益的是我们这些用数据库的人。

如果非要我给正在做选型的团队一个具体建议，我会说：别总盯着性能测试报告纠结数值得分，踏踏实实把你的业务场景、团队能力、运维资源摆到桌面上，让六家产品各自跑一遍你们自己的真实场景。谁的迁移成本最低、谁踩的坑最少、谁出了问题能最快找到答案，你就选谁。数据库没有最好的，只有最适合你的。

最后分享一个我的个人习惯：每接触一个新数据库，我都会花一个周末的时间，把它的官方文档从第一章读到索引页，把示例代码亲手跑一遍，把备份恢复脚本真实演练一次。这个习惯让我在国产数据库上少走了很多弯路。数据库这行，没有捷径，但每一个提前踩过的坑，都会在关键时刻替你挡一次刀。