眠子子子去年大促前的稳定性压测结束之后，DBA在群里丢了一条告警截图，说有一条运营后台发来的统计SQL把整个在线库打到了90%以上。那条SQL本身不算复杂，就是按券批次统计核销率，问题出在卡券业务的数据已经不是千万或者千万级别能收场的体量：领券记录、券码明细、核销流水加起来已经到百亿级别。任何一个稍微松一点条件的统计，在线库都得硬扛。
后来爱奇艺卡券业务做了数据库架构升级，核心方向是引入OceanBase，用“单库双擎”的思想，把原来分散在多套MySQL分片、多套离线数仓同步链路里的能力收敛回来，让在线业务和分析业务在同一个库底座上协同跑。这篇内容我梳理了很久，把整个升级过程拆成了几部分来写：为什么会选OceanBase而不是继续分库分表，迁移前最容易被低估的兼容性评估怎么做，单库落地时表结构、分区和索引要如何重新设计，双引擎场景到底靠什么技术实现，以及上线切流时压测和灰度的实际打法。最后我还会把这段时间踩过的坑和沉淀的OceanBase面试常考知识点一起整理出来。
1. 项目背景：百亿级卡券业务为什么需要做数据库架构升级
1.1 卡券业务的数据模型与痛点
卡券业务听上去简单，无非就是发券、领券、核销、过期。但一旦把它放在视频平台里，规模就不太一样了。平台促活要做签到送券，会员运营要做权益卡券，电商和游戏业务也会通过卡券做交叉推广，每个自然月都在新增大量券批次，每个批次又会给海量用户生成一张或者多张券。
业务的实体关系并不复杂。第一层是券批次，定义了券的类型、面额、有效期、库存、发放策略。第二层是券实例，批发下来之后每个用户实际持有的是批次里独立的一张券，有唯一券码，有领取人、领取时间、状态、核销单号。第三层是券的核销流水，记录每一次消费、退款、失效的具体行为。重点在于中间这张券实例表，当发放总量累积到百亿级别时，这张表的行数会非常可观，而且它还伴随极高的写入频率和状态变更频率。
这类业务有几个天然让人头疼的点。一是热点集中在有大量领取动作的券批次上，尤其是签到活动整点开启时，几百万用户在一瞬间去领同一批券，对库存扣减和唯一约束的要求很高。二是券状态会不断流转，已领、已核销、退券、过期，每次状态变更都是update，不是简单的insert。三是运营对分析的需求非常高，活动复盘时要看某个批次领取了多少、核销了多少、哪个城市的用户参与度最高、哪个渠道带来的转化最好，这就意味着数据库不能只干交易的活，还得能撑起比较重的查询。
1.2 老架构下“一个查询”引发全链路抖动
在转型之前，业务库用的是典型的MySQL分库分表架构，加了缓存应对读流量，每天还有一堆定时任务把在线库的明细同步进数仓。这套架构在业务量小的时候很顺手，数据到百亿，链路问题就越来越大。
先说在线库。单条数据不是不能存，但要支撑百亿行的扩展能力，必须做分片。分片一旦做了，SQL就有很多约束：跨分片事务不能随便用，跨分片join基本不可能，查询条件不带上分片键就会被路由到全部分片做扫描。
卡券业务里最简单的“我的卡包”查询，查某个用户手里有哪些券，按userId分片是没问题的。但如果运营想查某一个批次总共发出了多少张券，这个批次的券code分布在所有分片上，就真的只能去几十个分片里分别扫描再汇总。最初几条SQL可能还能凑合跑，到数据规模上来之后再配合大促，分片集群就很容易被这种统计类请求拖垮。运维团队那时候不得不设置超长SQL熔断，但熔断并不能解决运营要取数的问题，反而经常导致在线用户的正常领券受到影响。
另一个痛点是数仓链路的延迟和成本。每天晚上同步任务把券实例表的增量数据导到Hive或者其他数仓产品里，T+1才能看到前一天的结果。业务想要准实时看大促核销进度时根本没法支持。而且在线MySQL和数仓各存一份数据，这里面的存储成本和链路运维成本都不小，一旦同步任务延迟，数据对不上，还要花时间排查到底是业务bug还是同步工具的问题。
1.3 单库双擎要解决什么问题
当时我们复盘后得出的结论是：架构升级的核心目标不是单纯换一个更大容量的MySQL，而是要把数据库架构从“为了容量牺牲查询能力、为了分析引入同步链路”的旧范式，转变到一个更简单直接的模型上——一套数据库同时承载在线交易和实时分析。
这个方向实际上就是后来确定下来的“单库双擎”。单库，指应用层不再需要区分在线库和数仓，核心数据只住在OceanBase这一个大库里，存储物理上统一。双擎，指同一份数据既能以行存模式服务高频点查、短事务这类在线交易负载，也能以列存索引、并行执行等方式服务聚合统计、复杂过滤这类分析负载。过去那种“通过数据同步把在线库的数据搬到另一套系统”的常规做法，被拍扁成了一个数据库的两个执行路径。
这个架构有几个直接收益。第一，业务团队写代码不用再天天想数据在哪个分片、是不是跨片事务，OceanBase原生分布式会把分片调度隐藏掉。第二，券状态、核销流水这些明细数据可以实时被分析查询感知，业务决策从T+1变成准实时。第三，运维不需要维护一套额外的同步链路和一套额外的分析存储，链路短了，故障面也会缩小。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型：为什么我会把OceanBase放进候选名单
2.1 分库分表的终局，并不是换一个更贵的关系库
数据库选型时，市面上不是没有替代方向。很多人会提继续用MySQL，把分片数从64加到128甚至256，然后把跨分片查询统统改造走数据服务层。这个路线不是不行，但会把人力和成本都消耗在非常琐碎的事情上：数据节点扩容后数据要重新分布，迁移过程要保证不丢不重，分布式事务要自己实现补偿，跨分片统计查询要用额外的汇总服务。
OceanBase走的是另一条路。它对应用暴露的是一个分布式集群，内部由多个节点组成，但数据按照分区自动分布到不同节点上。应用连接以后，不需要感知某张表在哪个节点，也不需要在代码里做分片路由。表可以直接建成分区表，分区数量可以远超节点数量，并由OceanBase调度分布。
对于卡券业务这种百亿级数据场景，这意味着扩展性不再依赖“应用层分库分表中间件”，而是依赖数据库本身的分布式能力。实际运维时，节点不够就把节点扩进去，OceanBase会自动做负载均衡和副本迁移，不需要业务配合把某几张表迁移到新分片，对应用来说是透明的。
2.2 MySQL兼容模式对存量系统有多重要
没有任何迁移可以重写全部业务代码，所以在选型时我们非常看重兼容性。OceanBase提供MySQL兼容模式，兼容MySQL 5.7和8.0的大部分常用语法。这一点对当时存量系统非常友好，应用层的数据访问基本不需要大改SQL，切换成本就被压到了可接受的范围。
实际测试时，我们验证了包括多表join、子查询、窗口函数、事务隔离级别、自增主键等高频用法，绝大多数跑出来的结果和MySQL是一致的。细节上确实有差异，比如某些存储引擎状态变量、部分系统表、一些函数细节需要做适配，但整体比例不高，而且这些差异可以在迁移前通过工具扫描提前发现，风险可控。
MySQL兼容模式还带来了另一个好处，业务团队几乎没有学习成本。开发在本地写好的SQL，测试环境连上OceanBase后基本能原样跑通。从项目推进角度讲，DBA和研发不用先花大量时间适应一套新方言，整个团队的阻力会小很多。
2.3 行列混合存储，让一套库同时服务交易与分析
既然要做“单库双擎”，就要回答一个问题：数据库凭什么在同一个库里既扛住高频update，又扛住大范围聚合？如果只是简单地把MySQL升级成另一个关系库，聚合查询还是会慢，只不过从全表扫描变成全分区扫描而已。
OceanBase在存储层很有特点。它的存储引擎采用LSM-Tree架构，数据在内存中以增量写的形式更新，最终合并到磁盘，这让写入吞吐比传统B+Tree引擎高很多。同时，它的存储布局不是只支持一种形态，默认的日常写入和点查走行存语义，一张表可以再额外创建列存索引。列存索引会把同一个列的数据连续存放，配合向量化执行引擎，适合做按列聚合的统计查询。
这其实就是“双擎”在技术上的核心依托。在线交易产生的写入首先落在行存主表里，事务提交后，列存索引会异步或同步地同步更新。等到运营侧发起“按批次统计核销率”“按日期统计领券趋势”这种分析SQL时，优化器会选择走列存索引，把需要扫描的列数据用批量方式读出来，这个查询对行存主表的高频写入影响就会极小。
另外OceanBase的并行执行能力也不错。很多报表SQL在MySQL上可能用不上并行度，只能单线程扫描；OceanBase会把一个大查询拆成多个子任务在多个节点上并行跑，最后汇总。百亿行级别的表做聚合，如果SQL写得没问题、并行度设置合理，响应时间能从分钟级降到秒级或者更短。
3. 迁移前置工作：兼容性评估、数据同步与双跑校验
3.1 先用工具和人工把SQL兼容性查清楚
切换数据库最怕的事不是性能不够，而是上线后突然发现某条存量SQL在OceanBase上语法行为不一致，导致业务出错。所以迁移第一步不是直接拿生产流量来测，而是做一次全面的SQL兼容性扫描。
我们当时把应用侧所有涉及数据库的代码、MyBatis XML、存储过程中的SQL全部抽出来，然后做两层扫描。第一层靠工具，对比MySQL语法和OceanBase MySQL模式的兼容性检查项。第二层人工过重点，尤其是这几个高危场景：
- 索引组织表里常见的自增列、
VALUES LAST_INSERT_ID()返回值； - JSON字段和JSON函数，OceanBase对JSON的支持在逐步完善，项目里尽量少用复杂JSON表达式；
- 字符串比较、字符集和排序规则，如果建表时用了utf8mb4的默认排序规则，迁移后要确认一致，否则索引失效；
- 隐式类型转换的行为，MySQL里字符串和整数比较会转成浮点或整数，OceanBase某些版本存在差异，容易影响索引利用；
- 特殊保留字和注释语法，比如
--后是否需要空格、/*! */版本条件注释处理方式等。
检查结果需要输出成清单，每一类问题都必须有解决方案，是改写SQL、调整表定义、还是直接换个等价实现。不要留着“应该没问题”这种模棱两可的结论进上线评审。
3.2 全量同步与增量同步
当确认兼容性风险可控后，第二步是把MySQL里的存量数据迁移到OceanBase。数据同步工具上，能用的选择不少，常见的是OceanBase官方配套的OMS，或者其他异构数据同步组件。
全量同步阶段要关注几个方面。第一是资源，全量迁移会很耗源库的IO和CPU，建议在业务低峰期跑，并控制并发度。第二是数据一致性，不能只同步完字段数量一致就算完，要做行数校验、关键字段sum校验、抽样字段值比对。第三是自增列和唯一键，同步完成后要确认新的自增起点，避免迁移后主键冲突。
增量同步解决的是全量迁移期间新产生的写入。在线业务不可能停库等着，所以需要靠订阅MySQL binlog，把全量同步开始后产生的新增和变更持续发送到OceanBase。这里要注意同步的实时延迟和位点回退问题。一旦增量同步出现异常，要能快速定位到某条binlog，重放时不能产生重复数据，所以目标表的唯一键和幂等策略必须设计好，不允许简单delete再insert的同步逻辑在核心表上反复使用。
3.3 影子流量与结果校验怎么设计
数据同步做完了，不代表业务就能直接切。我们当时选择了一套比较稳妥的影子流量方案。
应用层加了一个切换开关。在灰度阶段，开关打开后，业务会把部分读请求复制一份，同时打到旧MySQL和新OceanBase，然后对比两边返回结果。读得到的字段如果不一样，就说明迁移流程里可能存在问题。这一步主要验证的是两条路径在真实业务SQL下的结果一致性，能抓到很多静态比对抓不到的问题，比如函数返回值、字段精度、NULL处理不一致等。
影子流量的对比逻辑要有一定的容忍度。比如时间字段、随机字段本身可能每次请求都会变化，就不要做全字段严格相等校验，要按业务主键做白名单字段对比。另外，影子流量会带来额外的数据库压力，需要控制放量比例，一般从1%或者5%开始，观察数据库负载和应用RT没有异常后再增加。
在校验通过后，才能进入真正的切流阶段。这个过程的经验是：宁可多花时间在校验上，也不要在切换后靠回滚去兜底。回滚永远都是最后手段，能通过前面的准备工作把问题堵住，是效率最高的做法。
4. “单库”落地细节：百亿行数据的分区与索引设计
4.1 选择分区键，不是看DBA心情而是看查询路径
同样的数据量放到OceanBase里，如果表结构设计不跟着变，效果会打折扣。最核心的是分区键选型和分区策略。
卡券业务里最典型的几张表，每张表的分区策略都不同。券批次表的数据量相对可控，按业务线做List分区即可；券实例表必须按使用场景来定。最初有人提议直接按hash(券码)做64个分区均匀分布，这样数据库层面的并发分散最均匀。但如果查询经常是按userId查卡包，按券码hash分区会导致一个用户的多张券散落到不同分区，每次点查都要跨分区，效率并不好。
所以最终选择了“userId优先”的思路。用户打开卡包时，一定是查看自己名下的券，按userId做Hash分区能保证同一个用户的券都在同一个分区内，点查可以走单分区，效率最高。对于某些批次维度的批量操作，虽然会跨分区，但这类请求本身就是低频的运营或定时任务，可以通过OceanBase并行能力去处理，不会成为用户体验路径上的延迟瓶颈。
分区粒度上，考虑到数据量会随着时间持续增长，最外层的范围我们选择了按月份做二级分区，在userId hash分区内又按月份范围分区。这样的好处是：用户查询会被月份条件裁剪，比如只看未过期卡券会默认限制到最近三个月，不会去扫历史所有分区。时间久了的过期数据，归档后可以直接drop掉对应的月份分区，不需要一条条delete。
4.2 索引设计：局部优先，能少建就少建
索引设计这块，最容易踩的误区是从MySQL时期直接补齐索引。业务的查询路径切到新库后，必须按新库的分区和执行计划重新梳理。
在线查询大致分三类：一是用户查自己的券列表，二是系统按券码核销时查某一张券，三是运营后台按批次或者状态做统计分析。第一类已经由分区键userId覆盖，主要再考虑状态和时间过滤，建一个(user_id, status, expire_time) 的局部索引就够了。第二类按券码查，因为券码本身是全局唯一键，需要用唯一索引去保证，这个索引可以实现为局部唯一索引或者全局索引，具体要看券码值的分布能不能结合分区键。第三类分析查询，通常不依赖二级索引，更多是走列存索引和并行执行。
建索引要克制。我曾经见过有人把一张百亿行的表建了七八个二级索引，每个索引维护都要消耗存储和写入性能。OceanBase的LSM-Tree在写入时虽然比B+Tree友好，但索引列一多，合并压力还是会变大。建议每个大表最多保留两到三个高频索引，低频查询交给列存索引或者走分析型查询路径解决。
4.3 状态流转和幂等控制在分布式库里的写法
卡券核销的状态流转很讲究。一张券不能被核销两次，也不能在核销后还能被退款逻辑再改回去。传统MySQL单库里可以用行锁和事务天然保证，切到OceanBase后同样可以，但要注意写法上把锁范围控制到最小。
推荐的写法是条件更新。例如核销时会执行类似下面的SQL：
sql复制UPDATE t_coupon_instance
SET status = 2,
consume_time = NOW(),
consume_order_id = ?
WHERE id = ?
AND status = 1;
执行后判断affected rows，如果等于1说明这张券确实是从未核销状态变更到了已核销，如果等于0说明状态不对，业务层就要抛异常。这种乐观锁写法比先select再update少了一次网络往返，也避免了并发下两个请求同时读到旧状态。
如果是用户领取场景，重点在防重。用户和券批次之间应该有一个唯一的领取关系，可以用(user_id, batch_id)建唯一约束。并发高的时候，数据库唯一索引天然能起到让一部分请求失败的作用，比应用层加分布式锁更直接。OceanBase在唯一约束冲突时返回的错误信息相对明确，但要注意，大流量下冲突的请求会占用连接和CPU，所以业务层还是需要先做一层本地去重或缓存标记。
4.4 历史数据生命周期管理
百亿行是一个会持续膨胀的指标，如果不做历史数据治理，任何数据库都撑不住。
我们的历史数据策略是分层的。运行中的在线数据保留在OceanBase主表，属于活跃数据。过期超过半年的券实例，每个月由归档任务迁移到冷存储，同时从在线表里把对应月份分区drop掉。这个动作相当于定期给数据库“瘦身”，避免表里全是状态为“已过期”的死数据占据扫描空间。
归档任务本身也要放在低峰期执行。OceanBase的分区drop是元数据操作，速度非常快，也不产生传统意义上的大批量delete日志。相比在MySQL里execute一条delete from t_coupon_instance where expire_time < ?扫几千万行，新方案在运维成本上确实是一种降维。
5. “双擎”怎么跑起来：让在线交易和报表分析共用一套OceanBase
5.1 给分析查询配一个列存索引
运行一段时间后，我们陆续在券实例表和核销流水表上建了列存索引，这是“双擎”场景真正跑起来的关键。
比如券核销流水表，字段有id、券实例id、用户id、批次id、核销时间、业务线、金额、渠道来源等。交易链路只需要按券实例id查流水，而行存主表完全可以满足。但运营要想看“某个业务线每天核销金额的趋势”，如果不建列存索引，需要把过去几个月的流水全部扫描一遍，即使分区裁剪能排除一些数据，剩下的扫描量依然很大。
建了列存索引后，OceanBase会把business_line、consume_time、amount等分析常用列独立压缩存放。分析SQL在查询中只读取涉及到的列，不触碰其他无关数据，整体IO量会大幅下降。叠加向量化执行后，一个原本需要扫几十亿行的聚合查询，反馈速度会快到运营可以直接在后台点刷新，而不需要再发工单等离线跑批。
需要注意的一点是，列存索引并不是越多越好。列存索引的构建和维护也有存储代价，建议只针对查询模式明确、扫描量大、聚合计算重的表建立。如果表本身的数据量小，行存已经能秒回，就没有必要建列存。DBA应该通过观察慢查询日志，把Top N的分析型SQL作为建列存索引的依据。
5.2 并行执行与资源隔离
分析任务和交易任务跑在同一个OceanBase集群，最担心的就是分析负载把交易链路拖垮。OceanBase解决这个问题的思路主要有两个：并行执行受控和租户隔离。
并行执行方面，一条聚合SQL如果被优化器拆成了32个并行子任务，意味着最多可能占用数十个线程同时跑。如果不控制并行度，运营一个重查询就能吃满整个集群CPU。所以在OceanBase侧我们需要针对不同账号做并发限制和并行度限制，比如运营后台使用的只读账号，查询并行度上限设为8或者16，查询超时时间做短一些，避免烂SQL长时间占着资源。
如果复杂分析真的很多，更彻底的方案是单独创建一个只读副本。交易流量读写主副本，分析流量读取只读副本，两边在物理资源上做隔离。这个能力在MySQL分库分表时代很难低成本做到，因为MySQL方案里副本一般只能承担读流量，但复杂的分布式事务对副本一致性要求更高。OceanBase通过多副本一致性协议和数据同步机制，让只读副本可以对外提供比较实时的读服务，延迟通常是毫秒级。
5.3 T+1跑批如何变成准实时分析
架构升级之后最明显的变化，是原来依赖数仓的一批报表场景可以直接下沉到OceanBase来完成。
卡券运营每天最关心的是发放、领取、核销三个漏斗。以前这个指标要等夜间数仓任务跑完，第二天早上才能看到。切换到单库双擎后，在线券状态和核销流水的变更已经实时落在OceanBase里，列存索引也是准实时更新的，运营看板直接查OceanBase就能看到截止到当前秒的数据。
当然，并不是所有数仓任务都会被替代。数仓里还有一些和卡券无关的复杂建模、跨域数据融合和长时间周期分析，这些依然留在数仓体系里。但我们把高频率、低维度的贴近业务分析从数仓搬回了OceanBase，数仓的同步耗时和压力也随之降下来了。这次升级带来的体会是：“单库”不意味着放弃数仓，而是帮数仓卸掉一部分重复且实时性要求高的活。
6. 上线切流：全链路压测、灰度切换与回滚预案
6.1 全链路压测做什么才有参考价值
很多项目上线前压测只是简单地对数据库发起几个并发点查，这种压测根本没意义。卡券业务的核心负载特征是读多写多且夹杂着轻分析和重分析，全链路压测必须模拟真实流量比例。
我们压测时重点盯三块。第一点是领券高并发场景。模拟多个批次同时被海量用户领取，验证OceanBase在处理唯一键冲突、库存扣减和热点分区写入时的行为。第二点是用户卡包查询场景，这部分原本是Redis缓存命中为主，但缓存穿透后落库的查询RT要达到预期。第三点是运营分析请求和交易流量混合的场景，在一个持续交易的压力下，随机抛出几类大聚合SQL，观测是否会拉高交易P999延迟。
压测结果不是只看平均耗时。OceanBase的LSM-Tree特性使得写入先在内存合并，内存达到阈值后会触发转储或合并，这个瞬间可能会产生RT毛刺。压测时如果只取平均延迟很容易漏掉毛刺，所以要把P99、P999单独拉出来看，观察毛刺出现的频率是否和合并周期吻合。
6.2 按照读多写少的原则分阶段切流量
切流方案一定要按风险从低到高分批执行，不可能一次性把全部流量切过去，即使你对新系统很有信心。
我们当时设计的切流顺序是：先切统计和报表类流量。这类流量在指定账号下跑的是分析型SQL，即使出问题也不会直接影响用户领券和核销，最安全。统计类流量在OceanBase上跑了一段时间且结果和旧逻辑一致后，再切读多写少的用户查询流量，把卡包查询、券状态查询逐步切到新库。这个阶段仍然保留双写或者同步链路维持两边一致性。
最后才是写流量的切换。写流量一旦切过去，意味着新增的领券、核销行为完全由OceanBase负责。为了保险，我们在切换前做了主备切换演练，模拟机器宕机、节点隔离等故障，确认OceanBase能在几十秒内重新选出主副本并恢复服务，才正式执行写流量切流。
整个切流过程我们保留了“一键回切”开关。一旦切换后出现重大问题，应用配置可以迅速把流量切回旧MySQL集群，同时让数据同步反向回传。回滚预案不需要多优雅，但一定要经过演练，否则线上出问题再临时想方案，时间根本来不及。
6.3 新数据库的监控指标和告警，不能再沿用MySQL思维
切到OceanBase后，DBA会发现自己面临一个“监控空窗期”。过去MySQL运维积累的告警阈值，比如线程连接数、慢查询数量、buffer pool命中率等，很多无法直接迁移到新的数据库体系。
我们上线前专门梳理了一套新的监控看板，重点看这些指标：
- 租户CPU和内存水位，OceanBase的租户有资源规格限制，超过后会排队。
- MemStore内存使用率，当达到阈值会触发冻结合并，频繁触发说明写入量过大或者内存规格不足。
- RPC请求耗时和网络连接数，很多SQL变慢不是计算慢，而是节点间的远程请求在排队。
- 副本同步延迟和主备切换次数。
- 大查询量和查询超时次数。
告警规则也不再沿用“连接数大于某个绝对值”这种静态阈值，更多采用动态基线。比如OceanBase的合并周期通常在凌晨低峰期，此时RT毛刺是可接受的，所以监控告警要区分时段和场景。如果白天交易高峰期出现多次合并导致的延迟毛刺，就需要考虑调大租户内存或者错峰执行合并任务。
上线后我们还建立了一个稳定性周报机制，每周看核心券表的TPS、RT、分区增长、列存索引命中情况等数据。前几周主要是调整一些参数和列存索引策略，整体稳定后就进入常态化运维。
7. 常见坑位与架构升级后的沉淀
7.1 OceanBase迁移中容易踩的8个坑
这次升级过程非常顺利，但中间也踩了不少坑。我把一些有代表性的问题整理成了一张速查表，供后续项目参考。
| 典型问题 | 现象 | 排查思路与解决方式 |
|---|---|---|
| 数据导入后主键自增错乱 | 新增记录与存量记录冲突 | 全量同步完成后使用 ALTER TABLE ... AUTO_INCREMENT 设置新起点，或者用雪花ID等应用生成主键 |
| 分区键和唯一索引冲突 | 建唯一索引报错或执行计划走全分区 | 把唯一的券码索引设计为全局唯一索引，或用“分区键+业务键”组合做局部唯一 |
| 连接数打满 | 应用报获取连接超时 | OceanBase租户连接数与MySQL概念不同，需按租户规格调整连接池和系统变量 |
| 大事务持续不提交 | MemStore内存持续上涨，触发频繁合并 | 应用层控制事务大小，批量刷数据时按千或万级别分批提交 |
| 分析SQL没有走列存索引 | 查询耗时依然很高 | 查看执行计划是否正确命中列存索引，确认统计信息已更新，必要时加查询hint |
| 并行查询占用过高CPU | 交易RT被拖高 | 对运营账号做并行度限制，查询超时收紧，把重分析路由到只读副本 |
| 查询结果和旧库不一致 | 影子流量校验发现数值差异 | 排查字符集/排序规则/浮点精度差异，统一建表规范和字段类型规范 |
| 数据同步位点卡住后重放重复 | 目标库出现唯一键冲突 | 同步工具需要幂等写入，重复insert要改成insert ignore或replace语义过滤 |
这些坑几乎都不是OceanBase本身有什么大缺陷，更多是两种数据库在运维理念、参数细节和执行机制上的差异。提前知道这些知识，后面的迁移排期会顺利很多。
7.2 从“超级大循环”到“事件驱动”的架构思考
这次升级里还有一层很有意思的架构思考，和嵌入式系统里常说的“超级大循环”到“事件驱动”演进有异曲同工之处。
旧架构里的很多统计任务，本质上是一个超级大循环：每天早上定时任务把全量或增量的券数据捞出在线库，再循环写到数仓，接着数仓再按用户要求跑来跑去。数据量变大时，这个大循环扫过的数据越来越多，循环周期越来越长，任何一个环节慢了都会影响整条链路按时产出。
切换到单库双擎后，核心数据的每一次变更都是数据库里的一个事件，通过事务日志记录、副本同步、列存索引更新，数据从一个状态迁移到另一个状态。业务查询不再需要人工去循环搬数，而是基于已经有序存储的数据直接取。这种从“定时循环搬数据”到“数据变更即时驱动下游消费”的思维转变，其实和事件驱动架构里“消息到了再处理”的思路是一致的。数据库层面的能力天然支持了这种演进，这是升级后系统不再臃肿的深层次原因。
7.3 OceanBase相关面试题怎么答才加分
这次项目之后，团队里不少同学出去面试都被问到过OceanBase相关的问题。有几个高频问题，我总结一下回答思路。
第一个问题是“OceanBase和MySQL有什么区别”。只答“OceanBase是分布式数据库”是不够的。有竞争力的回答要拆成几个层面来展开：存储引擎上，MySQL常用InnoDB的B+Tree，OceanBase是LSM-Tree；架构上，MySQL单机主备，OceanBase是多节点日志流多副本；扩展性上，MySQL要分库分表，OceanBase可以透明水平扩展；能力上，OceanBase支持行列混合存储，能跑HTAP负载。如果能结合这次卡券业务百亿行数据的案例，说明某个场景下为什么选OceanBase，面试效果会明显不同。
第二个问题是“OceanBase如何保证数据一致性”。回答要提到它采用Paxos协议，多副本写入法定数量后才返回成功，保证主备副本之间数据一致。同时通过内部MVCC机制保证事务读到的一致性快照，结合RPO=0等能力回答。最好能补充一点：手工切主或故障切换时，客户端感知到的时间窗口很短，从而体现分布式数据库相比传统主从切换的稳定性。
第三个问题是“分库分表和分布式数据库如何选择”。这个问题没有标准答案，但可以给出判断框架：如果业务体量已经大到要拆几十上百个分片，且团队持续投入在分片运维和跨片查询上成本很高，这时原生分布式数据库价值更大。如果团队业务简单，分片键稳定，未来复杂度可控，继续沿用MySQL分库分表也是合理选择。面试官想要听到的不是一种技术的无脑吹捧，而是你对复杂架构选型场景里的权衡。
第四个问题是“OceanBase的LSM-Tree为什么适合写入密集场景”。可以先对比B+Tree的随机写、页分裂和写放大，再解释LSM-Tree如何把随机写转成内存顺序追加，达到阈值后批量合并到磁盘。然后指出LSM-Tree带来的副作用——合并期间可能产生IO放大和延迟毛刺，所以生产环境要关注合并调度和内存水位。能把“好处”和“代价”都讲清楚，说明你不是停留在概念背诵层面。
我在这次升级里最大的收获，就是意识到所谓高性能数据库架构，不是单纯堆硬件或堆工具，而是要重新理解业务查询路径和数据生命周期，再匹配数据库底层的分区、索引、存储格式和并发能力。OceanBase对我们的价值，不只是容下了百亿行数据，更在于它让整个卡券业务的数据架构重新变得简单起来。如果你也在规划类似的升级，建议先别急着讨论哪款数据库更强大，把业务查询模型、数据增长趋势和存量SQL的真实行为摸清楚，再回头看技术选型，很多答案都会自己浮出来。