聊国产数据库能不能扛住核心业务，这几年我最大的感受是：问题很少出在数据库本身，多半出在把数据库当工具的人还停留在老旧思维里。核心业务对数据库的需求从来不是“能跑”——银行存贷、订单结算、库存台账、通信计费，这类挂了就要出大事的系统，要的是连续、准确、能秒级恢复。这篇文章我打算从架构部署、高可用切换、事务锁机制、备份容灾、迁移运维几个维度，聊聊国产数据库做核心业务可靠支撑时真正要面对的事，以及我踩过的坑。无论你是在做选型评估的架构师，还是即将把MySQL/Oracle迁到国产库的DBA、后端开发，这篇文章都值得你花十分钟慢慢看。
1. 先搞清楚：核心业务到底在向数据库要什么
1.1 别把“核心”两个字理解窄了
什么是核心业务？很多人第一反应是银行、证券、电信计费这种高并发金融系统。但核心业务其实是一种“挂了就要写事故报告”的业务形态，它不限于行业。比如连锁零售的库存账目、制造企业的生产工单、电商平台的下单支付链路，这些系统对数据库同样叫“核心”：数据不能丢、账不能错、用户操作不能被晾在半路。所以本文说的核心业务支撑，指的是对一致性、持续性、可恢复性有硬指标要求的一类业务场景。
在国产数据库替换的过程中，我见过很多团队把“核心”理解成“高并发”。他们拿压测工具打每秒几万笔事务，CPU没爆就觉得稳了。但真到了故障演练，一个主备切换把应用连接池搞挂，或者一条批量更新让备库延迟飙到分钟级，这时候才意识到核心业务的要求根本不是吞吐量，而是“在异常情况下还能给出正确结果”。这个认知差异，直接决定了后续架构设计和运维投入的方向。
1.2 可靠性不是不宕机，是四个可量化指标
国产数据库能不能可靠支撑核心业务，我认为要拆成四个可度量的维度来看。
- 连续性：数据库服务在故障发生后，业务的停顿时间有多长（通常用RTO衡量，核心业务目标一般是30秒到几分钟）。
- 一致性：节点切换、异常断电、并发写入之后，数据是否仍然满足约束，账目有没有多一分少一分（对应常规理解的RPO，极端情况下要求为0）。
- 确定性：同样的操作在任意节点上执行，结果是否可预期。这一点最容易被低估，尤其是从MySQL或Oracle迁过来后，不同数据库对事务隔离、唯一约束、函数行为的实现有差异。
- 可恢复性：备份是否真的能用，恢复流程是否真的跑得过。很多系统平时很稳，一到灾难恢复就暴露出备份文件损坏、归档日志断档的问题。
这四个维度缺一个，核心业务支撑都会出大问题。我后面几个章节的展开顺序，也基本就是沿着连续、一致、确定、可恢复这条线走的。
1.3 一个很容易犯的选型误区：拿老思路套新产品
接触国产数据库的团队，很多是从MySQL/Oracle切换过来的。这带来一个很自然的惯性：用MySQL的思维方式去理解国产库，拿Oracle的参数模板去调国产库，结果出了性能问题就一口咬定“国产数据库不行”。
实际上，主流国产数据库产品在架构上有各自的设计取向。有的产品偏Oracle兼容路线（比如金仓、达梦），有的产品偏分布式架构（比如GaussDB、OceanBase那种shared-nothing路线），还有的走分布式中间件加单体数据库的路线。它们对SQL语法、事务模型、分区方式的处理并不完全一样。所以选型和规划时，先别急着问“哪个国产库最强”，先问自己的业务对连续性、一致性、运维能力的真实要求是什么。核心业务支撑不是买一个最强引擎，而是把跑道修平整、把应急预案练熟。
提示：如果你的核心系统还带有大量存储过程、触发器、物化视图这类Oracle特性，优先考虑兼容路线更成熟的产品；如果业务本身是分布式读写模式，再考虑分布式架构。不要一上来就追求架构最复杂、最“先进”的方案。
2. 部署架构：可靠性的底子，在一开局就要铺对
2.1 单机、主备、共享集群怎么选
核心业务上国产数据库，首要问题是架构选型。很多人以为“高可用=主备”，这话对一半。主备架构能扛住服务器宕机，但扛不住磁盘损坏、机房级故障和误操作——误操作在主备复制下会被同步放大，数据错了两边一起错。所以核心业务到底用哪种架构，要结合业务对RTO/RPO的要求来定。
- 单机：适用于开发测试、非核心模块，成本最低，但出了故障只能靠备份恢复，不讨论。
- 主备复制：适用于RTO在几分钟内、能接受RPO可能不为0的业务（取决于同步策略），部署简单，日常运维工作量主要在看复制延迟。
- 共享存储集群：业界常用思路，多节点共享一份数据文件，RPO为0，故障切换快，但对存储设备稳定性要求极高，存储一旦抖动所有节点一起遭殃。
- 分布式多副本：适用于业务本身就是分布式的场景，牺牲一定事务一致性复杂度换取横向扩展和自动容灾。
我在银行类项目里看到比较稳妥的组合是：核心交易库用共享存储集群或同城双活，外围系统用主备，两地三中心走日志同步。国产数据库产品里，比如金仓、达梦都有对应的共享存储集群产品，也可以支持一主多备的部署，关键看有没有配套的仲裁机制。
2.2 外围条件比内核参数更容易翻车
很多团队把精力花在内核参数上，调一堆内存参数，反倒忽略了周边设施。可靠性的很多风险其实在外层。
第一是网络。主备库之间每秒都要传日志，网络一旦抖动，复制延迟就会飙升，严重时触发切换。这类问题用ping或丢包率根本测不出来，要看长期延迟曲线，比如每秒网络往返时间的99分位数。第二是存储。共享存储集群的核心依赖是仲裁磁盘和存储锁，存储设备如果自己出问题、光交换机抖动，故障切换的正确性就会受影响。第三是时钟同步。分布式事务、主备切换和日志排重都依赖时间戳，各节点时间差超过一定阈值，归档日志的定位、冲突检测就会出现怪异行为。这三样没有保障，内核再怎么调优也是白搭。
注意：在规划机房时，主备节点尽量分布在不同的电源域、不同的TOR交换机下面。不然数据库层面做得再高可用，一个机柜跳闸就把主备一起带走了，这种低端教训在真实运维里比比皆是。
2.3 部署层面我最建议盯住的三个细节
第一，数据库文件目录、归档日志目录、临时表空间目录要分盘。尤其是临时表空间和归档日志，很多事故都是临时表空间写满导致事务失败，或者归档日志所在的磁盘被历史文件塞满，备份任务悄悄失败。第二，端口、账号、数据库名这类元信息要提前定义好规范，别上线以后才想起要改，改掉一个库名或端口对连接字符串的影响面很大。第三，数据库安装完成之后立刻做一次全量备份并验证可恢复，不要等到业务跑了半年才第一次做恢复测试。这个习惯往里说，是给核心业务可靠的底子兜底；往外说，是保证你后续做迁移、升级都有退路。
3. 高可用切换：不是按个按钮，而是一整套可验证的动作
3.1 切换机制里最容易忽视的两个环节
高可用切换包含检测、仲裁、切换、对应用的影响几个环节，大部分人只关注“切换本身快不快”，却忽略了两个更要命的点。
第一个是脑裂防护。主备节点之间网络抖动时，备库可能以为主库失联，自己升任主库，形成两个“主库”同时对外提供服务，这就是脑裂。核心业务绝对不能接受脑裂后的双写。国产库一般都有类似仲裁（quorum）机制、日志比对之类的防脑裂设计，但在规划时一定要确认：当网络分区发生时，数据库到底会停写等待仲裁，还是直接进入风险状态。宁可切换到失败，也不能让两个主库同时存在。
第二个是应用层的“感知”问题。数据库切换完成后，应用如果还连着旧地址或者连接池里的连接已失效，业务一样不可用。你数据库切换只用了一秒钟，但应用重连花了十分钟，实际RTO是那十分钟，不是那一秒。很多国产数据库交付时会提供VIP（虚拟IP）漂移方案，就是把数据库故障对应用隐藏起来，但VIP方案本身也依赖ARP、二层网络，出问题的时候照样延迟。一定要在切换演练中把应用纳入进来，然后观察业务是否有感知。
3.2 演练要演得像真的，才算有效
在国产数据库切换演练上，我看到两种极端。一种是根本不敢演练，怕出问题影响业务；另一种是“演练”变成了提前通知所有人、在业务低峰期、所有依赖已备好的“表演”，一遇到真实事件还是手足无措。
真正有效的演练应该包含三类：计划内切换（主备互切，验证系统整体可用）、故障注入（直接kill数据库进程、断开网线、磁盘写满，看系统能不能按预期兜住）、恢复验证（备份数据恢复到新环境）。这三类题目要分开做、定期做，不要等到季度回顾才临时抱佛脚。如果你连备库都升不起来，那你做的一切高可用配置都只是PPT里的一页。
我这里有个小经验：第一次演练总会暴露出问题，这是正常现象。有一次我们做切换演练，数据库切换成功了，但一个定时任务因为连接池还在指向旧节点而报错，连带把下游一个报表任务搞挂了。事后查，是应用部署文档里的连接地址没有同步更新。这种坑不通过演练根本发现不了。
3.3 切换后要立刻检查的清单
主备切换不是算完“RTO达标”就结束了，切换后至少要做三件事：
- 检查新主库的日志应用状态、延迟是否为0，以及归档日志是否有断档。
- 检查应用连接数是否重新分布到新主库，连接池是否有大量报错、重试。
- 检查核心表的自增主键、序列号是否会出现冲突。很多国产库的主备切换后，序列（SEQUENCE）的步长没有对齐，导致新主库上插入记录时主键冲突，这类问题在平时看不出来，切换后才会显现。
这三条，每一条我都见过真实事故。比如序列号冲突，曾导致一个工单系统在切换后30分钟内无法创建新的工单，最后只能手工清掉序列缓存再重启应用。所以我的建议是，切换演练的结束标准不是“数据库起来了”，而是“业务核心链路完整回到健康状态”。
4. 事务、锁与并发：可靠性的另一条腿
4.1 隔离级别和MVCC，同名字不代表同行为
核心业务数据库的表面积可能不大，但事务逻辑往往很深。一条订单的创建可能涉及订单表、库存表、账户流水表、物流表，事务隔离级别稍有偏差，就会出现脏读或不可重复读。
国产数据库多数提供对Oracle/MySQL风格的兼容，但默认隔离级别并不统一。有的默认读已提交，有的默认可重复读。同是“读已提交”，不同数据库在部分场景下的表现也可能有微妙差异（比如快照生成时机、是否对DDL做特殊处理）。所以在迁移上线前，一定要把业务里所有关键事务挑出来，逐条确认它们在目标数据库上的隔离级别行为，不能只看文档上的“支持”两个字。
我见过一个迁移项目，业务方自信地说“我们用的是标准SQL，不用管隔离级别”，结果上线后线上对账出现差异，最后定位到是一个读取配置表的批量任务，在重复读隔离级别下跑到一半，配置表被另一个会话更新，读到新旧混搭的数据。这种问题在功能测试阶段极难暴露，因为数据量小、并发不高。核心业务要做到可靠，就不允许这种“赌运气”的假设存在。
4.2 死锁和锁等待：排查工具要趁手
数据库死锁、数据库并发锁，这两个词在运维群里永远有热度。核心业务一旦出现大量锁等待，最典型的现象是应用接口超时、部分会话堆积、数据库活跃会话数飙升。排查时先别急着杀会话，先看清楚锁等待的源头——是哪张表、哪个SQL、哪个会话占着锁不放手。
国产库大多提供了类似pg_stat_activity、v$session的视图，可以查会话状态、等待事件、当前执行的SQL。我习惯的排查顺序是：先看活跃会话TOP 10，确认谁在阻塞；再看锁等待链，找出谁等待谁；最后拿着阻塞者的SQL去问业务方“这个事务是不是忘提交了”。超过一半的锁等待事故，根因都是同一个：业务代码里开启了事务但没在finally里提交或回滚，连接归还到连接池后还带着未结束事务，下一个人拿着这条连接就卡住了。
注意：不要一看到死锁就重启数据库。绝大多数死锁是应用逻辑不严谨造成的（比如两条更新语句的加锁顺序不一致），重启数据库只会让现场证据消失，问题还会定期复发。正确做法是保留现场日志，把加锁顺序不一致的SQL找出来改掉。
4.3 连接池参数：不止是改个最大连接数
数据库连接池相关的问题一直热度很高，说明大家普遍被连接管理折腾过。连接池不是把最大连接数调大就算调好，核心业务更应该关注的是这几个参数：最小空闲连接数、连接最大空闲时间、连接最大生命周期、获取连接超时、泄漏检测。我个人项目里的建议是：最小空闲连接数不要低于并发峰值的一半，连接最大生命周期设为一小时以下，获取连接超时设置成5000毫秒到10秒之间。连接池里的连接如果长期占用不换，数据库侧的会话状态可能异常，比如某个会话持有的临时表空间没有释放、事务隔离级别被上一次操作改掉之类。
这里有一个很隐蔽的坑：连接池在数据库“故障”恢复后可能不会自动重建，池里的连接都是死连接。应用必须配置一个“连接有效性检测”来做心跳测试。检测SQL本身也要轻量，比如select 1。如果检测太复杂，连接池自己就变成了压力源。你以为你在做可靠性加固，结果多了一次查字典表的操作就把数据库拖垮了。
5. 备份、恢复与容灾：最后一道防线的实战设计
5.1 备份策略：物理备份和日志归档缺一不可
核心业务上国产数据库后，备份只能更勤快，不能因为觉得“自研数据库更稳”就放松。我的经验是：每天都做物理全备（或至少增量），日志归档要连续保留，周期至少覆盖最近7天，且要定期拷贝到异地存储。
这里有个容易被忽略的坑：归档日志的连续性。数据库每天产生大量归档日志，如果备份脚本只备份数据文件而不管日志，恢复出来大概率是一份“缺页”的数据。另一点，很多国产库在“非日志模式”下进行大容量操作（比如直接导入、批量加载）时会不允许执行，或者要求你先切换成日志模式再操作。有些团队为了图快，把数据库改成非日志模式跑批量，结果后续恢复时才发现那一批数据在日志里找不到。
注意：有些数据库报错信息会写“该数据库不可以执行非日志模式的大容量复制，请联系数据库所有者(dbo)”——这个报错看起来是权限问题，实际是在提醒你：核心业务的日志记录完备性比一次批量任务的速度更重要。不要为了性能牺牲可恢复性。
5.2 恢复演练：备份存在的意义是能还原业务
备份不验证等于没有备份。我建议每季度至少做一次完整恢复演练：把最近一次备份恢复到一台全新的测试服务器上，启动数据库，跑一遍核心业务健康检查SQL，对比关键表行数、最大订单号、当日流水是否一致。这套流程第一次跑会花掉大半天，但从第二次开始会越来越快，而且能沉淀出一份真正的“恢复作业指导书”。
恢复演练最常暴露的问题有三个：一是备份文件本身损坏，二是日志范围缺失导致恢复点达不到预期，三是恢复出来的库权限、对象元数据不完整。这三点只要暴露过一次，就会让你明白为什么“备份成功”和“备份可用”是两个完全不同的概念。平时多做一次演练，灾难时刻就少一分手足无措。
5.3 容灾等级：同城双活、异地灾备怎么谈
容灾不是越强越好，是匹配预算和业务等级。给核心业务定容灾等级，业内常说的标准大体可分三级：同城机房间热备（RPO≈0，RTO分钟级）、同城双活（RPO=0，RTO秒级到分钟级）、异地灾备（RPO分钟级到小时级，RTO小时级）。对大多数企业来说，第一个等级就足够应付99%的故障场景；真正需要异地灾备的，往往是受大范围故障影响极大的业务。
国产数据库提供的同步复制、异步复制、级联复制等能力，正好对应该三级容灾架构。部署时不要迷信“全是同步复制最好”，全同步对网络要求极高，抖动起来会拖慢主库性能，反而得不偿失。异步复制虽然RPO不为0，但在多数场景下已经是性价比最高的选择。容灾方案落地时，我建议把同步链路和业务链路在物理网络上做隔离或限速，防止灾备流量把生产网络打满。
6. 从MySQL/Oracle迁移：真正的考验往往是后半夜
6.1 迁移工具自带的“兼容性幻觉”
国产数据库大多提供迁移评估工具和在线同步工具——比如金仓的迁移工具、达梦的DTS等。这些工具能让表结构、数据大体搬过去，但搬不过去的是业务对旧数据库“性格”的依赖：隐式类型转换规则、字符串排序规则、日期函数行为、分区表表达式的写法、特殊字符转义。我在多个项目里发现，迁移完成后的前两周才是事故高发期，因为报表SQL、夜批任务、定时存储过程这些低频路径在迁移后才会逐个暴露问题。
所以迁移方案里一定要包含一个“影子系统并行期”：新旧两套系统并行运行3到6个月，同一笔数据两边写或者做核心表数据比对，等业务侧确认逻辑完全一致后再切换流量。这一步看起来周期长，其实是把不可逆风险转成可控增量。核心业务最怕的就是上线当天发现老逻辑迁移错了，数据已经写坏了，那个时候你连回退的余地都没有。
6.2 优化器差异：执行计划不会跟着你的老经验走
不少人从Oracle/MySQL迁到国产库后，最先遇到的性能问题是SQL变慢。常见原因是执行计划选择的索引和连接顺序不同，而核心业务SQL往往是多表关联JOIN，执行计划一变，响应时间就从毫秒级变成秒级。
遇到这类问题，要做的不是立刻改SQL，而是先看执行计划，确认实际走没走索引、驱动表对不对、有没有隐式转换导致索引失效。国产库大多支持explain、show plan这类命令，或者带可视化工具。跟DBA朋友聊天，大家一致的感受是：迁移后至少要留一个月做SQL性能回顾，把TOP 50慢SQL全部跑一遍执行计划对比。
这里也要提一下批量更新。有些语句看着简单，但如果字段是动态生成的表达式，批量更新时可能因为表达式求值顺序、函数确定性等差异，在不同数据库里结果不同。比如四百多条数据更新一个字段，字段正好是一个动态值，这种SQL在旧库上跑得好好的，换到新库就可能出现部分行没更新、更新后数值不符合预期。所以迁移或新上线时，凡是涉及动态值更新、函数计算的SQL，一定要先在测试库上验证逻辑，再放生产。
6.3 监控体系：从“看到进程活着”到“看懂风险趋势”
核心业务数据库的可靠性，最后要落到一套能提前预警的监控体系上。我建议重点盯以下指标：活跃会话数、等待事件、主备复制延迟、日志归档中断、临时表空间使用率、慢SQL数量、锁等待队列长度。这些指标最好做成趋势面板，而不是只做阈值告警——单纯阈值告警常常等数值飙红了才收到短信，趋势面板能看到风险来临前的斜率。
此外，监控数据库时不要把目光只停留在数据库实例本身。底层磁盘延迟、网络延迟、CPU队列长度、操作系统内存交换这些基础设施指标，对国产数据库同样重要。很多时候“数据库慢”的根因在底层的IO或网卡丢包，数据库层的指标只是症状。要建立一个习惯：看到数据库异常先看宿主机和存储，再看数据库内部，顺序反了会浪费大量排障时间。
7. 我自己踩过的几个坑
最后分享几个贯穿项目始终的真实教训。一是，高可用架构定得再完美，如果不定期演练，到了真正故障时你会发现自己对切换流程的熟悉程度还不如一个实习生。二是，备份策略只要是纸面的，就等同于没有；一份没被验证过的备份，在灾难面前比打不开的保险箱更让人绝望。三是，迁移项目的成败不取决于迁移工具，而是取决于你对业务SQL的理解和评估。国产数据库不是某个产品的名字，是一类产品的集合，每个产品都有自己的“性格”，要像熟悉老战友一样熟悉它们的真实行为，而不是听信任何一句“完全兼容”。
这些坑，每个都花过团队不少加班时间。写出来是希望后来者能少走几步弯路。核心业务的可靠支撑，说到底是一场持续的设计、验证、再设计的工程实践，从来不是一次上线仪式就能宣告完成的事情。
