从MySQL到分布式：一个考试系统数据库的演进之路
“考试开始五分钟，数据库连接池满了。”
“交卷那一分钟，慢查询把CPU打满，整场考试的人都在转圈等提交。”
做过在线考试系统的技术人都知道，数据库是整个架构中最容易成为瓶颈的地方。应用服务器可以横向扩展，负载均衡可以分流，缓存可以挡读压力——但数据落盘的写压力，最终都要汇集到数据库。当考生规模从百人到千人、从千人到万人，单机数据库迟早撞上那堵墙。
本文以宏远培训考试系统的数据库架构演进为线索，拆解数据库从单机MySQL到分布式架构的完整升级路径，重点介绍OceanBase等分布式数据库在考试场景中的落地实践，以及不同规模下的技术选型参考。
一、单机MySQL时代：够用，直到不够用
绝大多数在线考试系统，起步阶段都是单机MySQL。宏远也不例外。
几百人的考试，数据库压力不大。考生信息、题库数据、试卷结构、答题记录，几张核心表加几个索引，一条SQL下去毫秒级返回。开考瞬间几十人同时进入，交卷时几十人同时提交，MySQL应付得轻轻松松。
问题从并发量越过某个阈值开始出现。
首先是连接数瓶颈。考试场景的数据库连接不是均匀分布的——开考、翻题、交卷三个时刻，数据库操作密度瞬间飙升。连接池设小了，请求排队等连接，考生端转圈；连接池设大了，数据库本身撑不住，CPU报警。
其次是写入瓶颈。交卷高峰时几百上千人同时提交答案，每条INSERT都要落盘。单机MySQL的写入能力受限于磁盘IO，一旦写入请求堆积，不仅写入变慢，读操作也被连带拖垮——读写共用一个实例，写操作的锁和磁盘争抢会阻塞读操作。
再其次是数据量瓶颈。一场千人考试的答题记录可能就有几十万条，加上题库、试卷、日志、监控数据，单表数据量轻松破千万。查询性能开始劣化，慢查询越来越多，加索引治标不治本。
最后是可用性问题。单机意味着单点故障。数据库一宕，整场考试瘫痪。虽然可以搭主从做高可用，但主从切换有时间差，考试场景对中断零容忍。
这个阶段的技术方案通常是“堆配置”——换更强的服务器、上SSD、加大内存、优化SQL。这些操作能续命，但治不了根。当考生规模突破万人，单机MySQL的天花板就实实在在地到了。
二、读写分离+缓存：续命方案，但不是终极解
单机扛不住之后，宏远的第一步升级是读写分离。
主库负责写入——答题记录、交卷操作、日志写入全部走主库。从库负责读取——试卷加载、题目浏览、成绩查询分摊到多个从库。通过数据库中间件配置，读写操作自动路由到不同实例。
同时引入Redis缓存层，把高频读数据挡在数据库门外。试卷内容、考生登录状态、答题进度暂存，全部放到Redis。数据库的压力骤降。
这套方案在千人到数千人规模能撑相当长一段时间。但它有几个致命短板：
一是主库仍然是单点写入。读写分离只分摊了读压力，所有写入操作还是集中在一台主库上。考试场景的写入峰值集中在交卷时刻——几千人同时提交答案，主库的写入压力线性增长，分离再多从库也帮不上忙。
二是缓存和数据库的数据一致性问题。答题进度暂存在Redis，如果Redis宕机，缓存数据丢失，考生的答题记录就没了。虽然可以通过持久化配置和同步策略来降低风险，但架构复杂度也随之上升。
三是运维成本开始膨胀。主从切换、缓存失效、数据同步延迟——出问题时排查链路变长，对运维团队的要求明显提高。
对于万人级并发，这套架构的写入瓶颈和可用性短板仍然存在。需要一个能横向扩展写入能力的方案。
三、分库分表：把鸡蛋放到多个篮子里
读写分离不够用之后，自然会想到分库分表。
按考试场次或机构维度拆分——不同考试的答题数据落到不同库、不同表。一场万人考试的数据被拆成多个分片，每个分片独立处理自己那一份读写请求，单个数据库实例的压力大幅降低。
宏远在服务部分超大规模客户时，曾采用过这一方案作为过渡。但分库分表是重武器，代价很大。
首先是业务侵入性强。SQL不能随心所欲写了——跨分片查询不支持、Join操作受限、聚合统计需要跨多个分片取数据再合并。以前一个简单的“统计本场考试平均分”，分库后可能要先从十几个分片各取一份数据，再到应用层聚合。
其次是运维复杂度剧增。分片多了，备份、恢复、扩容、数据迁移，每一项操作的工作量都成倍增长。分片键的设计一旦定下来就很难改，业务需求变了，分片策略未必跟得上。
最关键的是，分库分表之后，系统失去了数据库层面的全局事务能力。答卷提交和成绩更新这两个操作如果在不同分片上，如何保证一致性？这需要引入分布式事务方案，而分布式事务的性能代价和复杂度又是一个大坑。
很多团队走到了这一步就卡住了：不分，撑不住；分了，hold不住。
四、分布式数据库：换个思路，让数据库自己扛
分库分表的本质，是把分布式问题从数据库层转移到应用层。开发人员需要自己处理路由、聚合、事务——这些本来是数据库该做的事。
分布式数据库的思路正好相反：把分布式能力内建在数据库内部，对应用层透明。
以OceanBase为例。OceanBase是蚂蚁集团自研的原生分布式数据库，采用Shared-Nothing架构，数据自动分片并分布在多个节点上。应用层看到的仍然是一张逻辑表，无需关心数据存在哪个节点上。跨节点的查询、事务、聚合，由数据库引擎内部完成。
在在线考试场景中，OceanBase的几个特性精准命中了单机MySQL时代的痛点：
写入水平扩展。交卷高峰时的大量写入操作，自动分散到多个数据节点并行处理。不是一台服务器在扛写入，而是一个集群在分摊。随着考试规模增长，增加节点即可线性提升写入能力。
原生高可用。数据多副本存储，单节点故障自动切换，RPO为零，RTO在秒级。考试进行中某台服务器宕机，考生无感知。这份高可用能力是数据库内置的，不需要额外搭建主从复制和切换脚本。
全局事务一致性。分布式事务由数据库引擎保证，应用层不需要引入额外的分布式事务中间件。答卷提交和成绩更新在一个事务内完成，数据一致性有保障。
HTAP能力。OceanBase同时支持OLTP和OLAP，考试过程中的高并发事务写入和考后的统计分析查询可以在同一套系统内完成，不需要把数据导出到分析型数据库再做报表。
五、宏远的实践：OceanBase在万人考试场景中的落地
宏远培训考试系统在支撑万人级高并发考试的过程中，完成了从MySQL到OceanBase的数据库架构升级。以下是几个核心实践要点。
迁移路径：通过OceanBase官方迁移工具OMS完成全量数据迁移和增量实时同步。得益于OceanBase对MySQL协议和语法的兼容，现有考试系统代码中绝大多数SQL无需修改，业务改动成本可控。
性能表现：迁移至OceanBase后，在数万人同时在线考试的场景下，交卷高峰期的数据库响应延迟从原来的秒级降低到毫秒级。某大型国企年度合规考试中，系统平稳支撑了超过三万人同时在线，数据库层面零故障，交卷成功率保持在99.9%以上。
运维简化：原先需要维护的主从复制、读写分离中间件、分库分表路由逻辑，全部由OceanBase内置能力接管。运维团队不再需要关心数据分片策略和节点间数据同步，故障切换对业务完全透明。
调优经验：迁移过程中也积累了一些关键经验。索引和查询需要在OceanBase环境下重新做执行计划分析，分布式环境下的查询优化策略与单机MySQL有所不同。热点数据（如正在进行的考试场次数据）需要特别关注分片键设计，避免所有请求集中到单个节点造成热点问题。
六、技术选型对照：你的系统该用哪种方案？
没有最好的数据库，只有最适合当前阶段的方案。
单机MySQL：适用考生规模在千人以下，考试频次低，并发压力小。优势是运维简单、团队熟悉、成本低。
读写分离+Redis缓存：适用考生规模在数千人，读多写少，峰值可控。优势是不需要大幅改造业务代码，架构过渡平滑。
分库分表：适用考生规模在万人左右，写入压力已经无法用单机解决，但团队有较强研发能力来维护分片逻辑。优势是成本可控，缺点是运维复杂。
分布式数据库（OceanBase等）：适用考生规模在万人以上，对写入水平扩展、高可用、数据一致性有硬性要求，且希望运维成本可控。宏远的实践证明，这套方案在万人级考试场景中表现稳定，性能天花板远高于传统方案。
七、结语
考试系统的数据库演进，从MySQL到分布式，是一条被业务增长逼出来的路。单机扛不住的时候，缓存和读写分离能续命；续命续不动的时候，分库分表能再撑一程；当分库分表的复杂度反过来吞噬研发效率时，分布式数据库提供了另一种选择。
宏远从MySQL走到OceanBase的过程，是考试系统技术架构伴随客户规模共同成长的一个缩影。目前国内分布式数据库赛道上，OceanBase是少数经过超大规模金融核心系统验证的产品。对于正在规划考试系统技术架构升级的团队，如果有万人级以上高并发考试的需求，可以参考宏远的实践路径，把OceanBase纳入选型考察范围。最终选什么，取决于团队能力、业务规模和技术债务——架构选型没有银弹，只有在合适的时机做合适的选择。