上个月帮一个电商客户做性能诊断，这个案例挺有代表性，值得展开说说。

背景是这样的：业务涨得猛，日活从50万翻到120万，QPS从3000飙到8000。应用层横向扩了好几轮，前端接口响应都挺快，但数据库连接池还是频繁打满。慢查询日志一个小时能涨几百条，告警群里全是红色消息。

老板一看就急了，说加机器。运维说加从库做读写分离。

我说，先别急，让我看看再说。

我登录数据库服务器，先查等待事件：

-- 查看InnoDB等待事件分布
SELECT event_name, count_star, sum_timer_wait/1e12 AS total_sec
FROM performance_schema.events_waits_summary_global_by_event_name
WHERE event_name LIKE 'wait/synch/mutex/innodb/%'
   OR event_name LIKE 'wait/io/file/innodb/%'
ORDER BY sum_timer_wait DESC
LIMIT 10;

-- 查看当前锁等待情况
SELECT * FROM information_schema.innodb_lock_waits;

排在前面的是Innodb_row_lock_waits和log_file_write，两个都是写入相关的等待。再看执行计划，大量INSERT走的是聚簇索引末尾追加，页面分割频率很高，Innodb_buffer_pool_pages_dirty比例居高不下。

这就很清楚了。瓶颈根本不在读，在写。

问题的根因是自增主键导致写入热点集中在最后一个数据页。几千笔订单每秒写入，全打在同一个页上，B+树页分裂不断发生，行锁全堵在热点页的最后几行。而且innodb_flush_log_at_trx_commit设的是1，每笔事务提交都要fsync刷盘。写入量一上来，日志写入本身就成了瓶颈。

说白了，读写分离只对读多写少的场景有用。写入是瓶颈的时候，加再多从库也白搭，主库的写入压力一点没减轻。

最后怎么解决的？三板斧：第一，把自增主键改成雪花算法生成的分布式ID，写入打散到多个数据页，消除热点。第二，innodb_flush_log_at_trx_commit调成2，接受一秒内的日志丢失风险换取写入吞吐。第三，批量提交代替逐条提交，减少fsync次数。调完之后写入QPS从2000提到了5500，连接池终于不打满了。

今天就借这个案例，聊聊OLTP场景下数据库选型到底该看什么。选错数据库，光靠调参是救不回来的。

OLTP为啥容易崩，瓶颈藏在IO和锁上

OLTP系统的核心特征大家都知道：短事务多、并发高、要求低延迟。衡量指标无非就是TPS、QPS、平均响应时间。

但实际踩坑之后你会发现，OLTP的性能瓶颈往往不在CPU计算上，在IO和锁竞争。两个常见的场景：

热点行竞争：电商下单、库存扣减、账户余额变更，大量事务抢同一行。行锁排队等，延迟从毫秒级飙到秒级。InnoDB的行锁虽然粒度小，但热点行场景下跟表锁没太大区别。

日志写入瓶颈：WAL日志虽然是顺序写，但每次fsync都是物理刷盘操作。并发事务一多，日志写入队列排队，事务提交延迟就上去了。这个瓶颈不解决，其他优化都是白搭。

而且OLTP有个特点，前端响应时间的要求很苛刻，超过200毫秒用户就能感知到卡。数据库慢一点，整个链路的延迟就被放大。

所以选型的时候，不能只看峰值TPS，还得看在高并发下的延迟分布。P99和P999才是决定用户体验的关键指标。

选型看什么，四个关键维度

干了十五年数据库，说说我评估OLTP能力的几个角度。

并发连接管理：老办法一个连接一个线程，3000并发就是3000个线程。每个线程默认栈内存1MB，光栈就好几个G。上下文切换的开销也不小，CPU忙着切线程，实际干活的时间反而少了。

写入路径：WAL日志怎么写的，有没有组提交（Group Commit），支不支持批量刷盘。组提交能把多个事务的日志合并成一次fsync，吞吐差距非常大。没有组提交的数据库，并发写入的时候每个事务都要等自己的fsync完成，日志盘的IOPS很快就成瓶颈。

优化器能力：走错执行计划比缺内存更致命。一条多表JOIN的SQL，本来该走索引嵌套循环，优化器选了全表扫描加排序，执行时间从5毫秒变成500毫秒。优化器的能力决定了应用SQL的真实性能，比加硬件管用。

成本和生态：授权费、运维工具链、社区活跃度、技术支持响应速度。这些"软实力"平时感觉不到，出事的时候才知道有多重要。凌晨三点数据库挂了，技术支持半小时响应和两小时响应，区别可太大了。

几个典型方案，挨个说说各自的问题

Oracle：老牌选手，共享服务器模式（Shared Server）成熟，连接池支持完善。写入路径也稳，日志写入优化做得早。SQL Plan Management功能可以在版本升级时锁定执行计划，避免回归。但就一个字——贵。信创背景下，Oracle的替代是迟早的事。很多团队不是不想换，是不敢换，怕兼容性出问题。

MySQL：中小规模用着挺舒服，生态好，上手快。问题在于并发写入一上来就暴露硬伤。主库写入一快，从库追不上，单线程复制导致读写分离废了一半。连接数超800之后断崖式下跌，Thread Cache命中率骤降，线程创建销毁吃掉大量CPU。优化器在子查询优化、分区裁剪这些场景也经常选错执行计划。

OceanBase：金融场景有落地案例，分布式架构确实能扛。但分布式事务要跨节点协调，两阶段提交的网络开销不小。有个容易被忽略的点——数据量不大、单机能扛住的时候，集中式方案反而更快，少了一层网络调用。运维门槛也高，OBServer节点扩缩容、合并流程、转储策略，得考虑团队DBA能不能接得住。

聊聊KES的几个设计选择，高并发场景实测

我测过不少国产数据库，KES在高并发这块有几个设计选择值得说说。

先说连接管理。KES用的是线程池模型，不是MySQL那种一连接一线程。后台线程池负责处理客户端请求，连接断开不影响线程复用。千级并发连接的时候，内存占用比MySQL低不少。

-- 对比连接数与内存占用（MySQL为例）
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Threads_running';
-- 结合OS层RSS内存，观察连接数攀升时的内存曲线

我做过对比测试，同样3000并发连接，MySQL的RSS内存涨到12G，KES大概7G左右。连接风暴场景下，KES的表现明显更稳，不会出现线程暴涨导致的CPU抖动。

写入路径：支持组提交和批量刷盘，日志写入走并行机制。高并发INSERT场景下，吞吐比传统单线程写日志有明显提升。我用sysbench跑了oltp_write_only的压测：

# sysbench 写入压测示例
sysbench oltp_write_only \
  --mysql-host=127.0.0.1 --mysql-port=54321 \
  --tables=16 --table-size=1000000 \
  --threads=512 --time=300 \
  --report-interval=10 run

并发512的时候，KES的TPS比同配置MySQL高30%左右。核心原因就是组提交把fsync的开销摊薄了，日志盘不再是瓶颈。

再看优化器。KES基于代价做优化，针对国产硬件的内存和IO特性做了适配。跑下来执行计划稳定性还不错，很少出现选错索引的情况。特别是多表JOIN的场景，Join Order选择比MySQL的优化器更合理，不容易出现笛卡尔积式的执行计划。

高可用方面，KES支持共享存储集群方案，主备切换能做到秒级。这一点在OLTP场景下很关键，业务不允许长时间中断。比起传统的流复制方案，共享存储没有数据追赶的过程，切换更干净利落。

整体架构偏OLTP优化，适合需要高并发写入能力的业务场景。

四点建议，给正在选型的兄弟

选型不是比参数，是比匹配度。

用真实业务SQL压测，别拿标准测试工具的数据自欺欺人。sysbench的oltp_read_write只能做参考，你的业务SQL长什么样，有几表JOIN，有没有热点行，这些只有拿真实流量跑了才知道。

看P99延迟，别只盯平均值。平均50毫秒挺好看，但P999到500毫秒的话，前端用户就能感知到卡了。压测的时候把延迟分布打出来，重点看长尾。一个请求慢了，整个页面就慢了。

试一下连接数打满时的表现。优雅降级和直接崩盘，差距不是一点半点。有些数据库连接数一超限直接OOM重启，有些能排队等待，体验完全不同。建议用连接池逐步加压，观察数据库在临界点的行为。

评估运维工具链。监控指标是否丰富、备份恢复是否方便、故障切换是否自动。这些在出事的时候才知道有多重要。好的运维工具能让你在凌晨三点少掉几根头发。

最后说几句掏心窝的

OLTP选型这事，关键不在哪个数据库跑分更高。性能、成本、运维复杂度，这三样找到平衡点才是正经事。没有完美的数据库，只有更匹配你业务场景的数据库。

数据安全法和个人信息保护法落地之后，关键基础设施的数据库选型已经不只是技术决策了。信创替代是大势所趋，选型不光要看当前的产品能力。产品路线图和生态兼容性也得看，这个选择关系到团队未来几年的技术投入方向。选错了，迁移成本比选型成本高十倍都不止。

KES在Oracle兼容、高并发OLTP和自主可控这三个维度上，交出的答卷还不错。特别是从Oracle迁移过来的场景，KES的SQL兼容性可以省掉大量改写工作。如果团队正在做Oracle信创迁移，KES建议重点评估一下。

各位在OLTP选型上还踩过哪些坑？评论区聊聊，互相学习。