大厂男孩的粉丝很多第一次打polardb数据库比赛的人，都会有一个共同的误判：把精力全砸在某个函数的微调上。我见过有队伍两个星期都在打磨同一个索引查找的位运算，跑分依然垫底，原因很简单——他们没搞懂这种比赛真正考察的是整个数据库内核在混合负载下的综合表现。polardb数据库比赛和平时做业务系统的SQL优化完全是两码事。业务系统里你面对的是一个已经成型的数据库，能做的主要是加索引、调参数、改SQL；而这类比赛要求你从内核层面去解决存储结构、事务并发、日志提交等一连串问题，评测模型会同时考察吞吐、延迟、正确性和边界行为。这篇文章就按我自己的参赛复盘思路，把一套可以复用的polardb数据库优化方案拆开讲，覆盖从评测模型分析、性能瓶颈定位、存储索引优化、事务并发控制，到日志提交调优和正确性验收的完整链路。
1. 先认清评测模型：数据库比赛比的不是单点性能，而是混合负载下的稳定性
拿到赛题的第一件事，一定不是读源码，更不是上网找各种别人现成的补丁，而是把评测模型吃透。这类比赛的评测方式通常可以分成两大块：一是并发压力下的性能评测，二是正确性校验。性能评测一般会用一批客户端线程，持续往数据库里灌增删改查混合负载，统计固定时间窗口内的总事务数、平均延迟或者尾部延迟。正确性校验则穿插在线程运行过程中，随机制造回滚、唯一键冲突、主键覆盖、多版本读等场景，最后核对数据最终是否一致。
1.1 为什么评测负载结构决定你的优化优先级
很多人把优化做反，就是没有从评测负载反推优先级。如果负载以点查和短事务为主，那么索引路径、缓存命中率和锁竞争就是重点；如果负载是大批量写入，那重点立刻转到日志刷盘策略、B+树节点分裂和写放大；如果混入了大量更新同一行的热点事务，锁粒度就是生死线。
我的建议是先根据赛题给的事务比例做一张推导表：每个操作背后涉及哪些内核模块、哪些锁、哪些磁盘IO，然后对照自己队伍的技术短板确定时间分配。常见问题是队伍里每个人都想写复杂模块，结果一块都没做完。宁可先把某一整条路径焊死，也不要每块都写一半。比赛给的时间有限，深度永远比广度值钱。
1.2 性能成绩的“非线性”陷阱
还有一个容易被忽略的点：评测分数的最终表现往往是非线性的。比如你把并发从16路提升到32路，吞吐不仅没有提升反而下降，说明锁竞争已经到了瓶颈；此时把单线程内的某个小函数优化得再好，对总分的影响都不大。反过来说，如果测试模型里有大量只读快照查询，把读路径的锁摘掉，可能直接带来数倍的提升。这就是为什么必须先跑默认代码，测出当前系统的扩展性曲线，再决定往哪个方向动手。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 动代码前先做两件事：搭建观测链路和锁定第一版基线
很多队伍一上来就大改存储结构，改完又不知道怎么验证是否变快，凭感觉说“应该会好一点”。这是比赛里最危险的状态。你没有观测工具，就无法判断瓶颈在哪里；你没有基线数据，就无法证明优化有效。所以开赛前两三天，哪怕不做任何功能开发，也建议先把观测和基线这两件事做扎实。
2.1 用perf加火焰图定位CPU时间到底花在哪儿
在Linux环境下，最直接的工具就是perf。整个过程三步走：
先用压测工具跑一个稳定负载，让CPU占用尽可能跑满，然后采样，再把采样结果生成火焰图或直接读报告。
使用的命令大致如下：
bash复制perf record -F 99 -p <pid> -g -- sleep 30
perf report -g graph --no-children
读报告时重点看三件事：锁等待相关的自旋函数栈，内存拷贝和哈希计算的热点，日志刷盘或系统调用导致的用户态与内核态切换开销。如果sys占用的比例明显偏高，说明内核模块跟用户程序之间的交互设计可能有问题，而不只是代码本身慢。
在此基础上，建议再做一个微型的计数埋点。在你的存储引擎事务提交入口、锁获取入口、日志写入入口各加一个原子计数器，压测结束后直接把命中次数打出来。这一招看起来土，但在比赛阶段往往比火焰图更直接：你能立刻看到“一个查询平均要拿多少次锁”“一次提交要触发多少次日志写”。
2.2 基线怎么看：先单线程找延时，再并发找扩展性
第一版跑通后，不要急着优化。先记下一组基线数据：单线程下各类操作的延迟、CPU单核能跑到的极限TPS，以及多线程扩展曲线。用原版代码把这三个数据拿到手，后面每次改动都拿相同负载去对比，能省下大量无意义的返工。
我会额外测一个“理论性能上限”：把持久化完全关闭、锁全部换成空的、所有数据都放内存，看看纯计算路径能跑多快。这个值虽然不真实，但它能告诉你当前系统的性能天花板在哪里。如果你的优化已经非常接近这个天花板，说明瓶颈已经不在代码路径，而在评测负载本身或并发模型设计上。
3. 存储与索引路径上，最容易出成绩的三类优化
数据库内核的性能，最底层取决于数据怎么存、索引怎么找。这一层优化收益巨大，但需要正确性校验兜底。围绕polardb系引擎的架构特点，我建议优先关注三类：页面大小与缓冲池配合、索引结构的紧凑性、缓存友好度。
3.1 页大小、缓冲池与内存命中率的关系
存储引擎访问数据时一般以固定大小的页为单位。页太大，一次IO能覆盖的数据多，但页内更新造成的写放大也更大，而且缓冲池能容纳的页数会变少，热点数据容易被淘汰；页太小，点查的随机IO反而更多。比赛评测机的内存通常是有限制的，你要先保证“热数据基本落在内存里”，再去谈页大小问题。
具体做法是先用压测连续跑几轮，观察缓冲池的命中率。如果命中率长期在99%以下，说明要么数据量超过内存太多，要么页面淘汰策略有问题。淘汰策略上，简单的LRU在顺序扫描场景下很容易被污染——一批全表扫描把真正热的数据全部挤出缓冲池。可以换成冷热分区的改进型LRU，或者手动在扫描路径上标记“低复用度页面”，避免扫描污染缓存。
3.2 从B+树扇出到前缀压缩，每一个字节都值得抠
索引的主要矛盾是：既要快速定位，又不能占用过多内存。B+树的层数直接影响点查要走多少次指针跳转，而层数又由节点大小和键的长度决定。压缩索引键长度是性价比很高的手段。
最常用的技术是前缀压缩。如果索引里连续键的前缀高度重合，比如字符串以相同固定前缀开头，就可以只在叶子节点或内部节点里存放差异部分，公共前缀放到节点头部一次保存。这会降低索引的内存占用，提高节点可保存的键数量，从而降低树高。比赛时间有限，如果引擎已经支持变长键存储，可以优先改造这一处而不是重写整个索引结构。
另一个值得抠的点是行存储格式的紧凑性。把不定长字段的偏移表精简掉、把标志位压缩到bit级别、去掉冗余的元数据头，在大量扫描时能显著减少CPU的解析时间，同时提高CPU缓存的有效利用率。
3.3 让索引查找尽量落在CPU缓存里
内存数据库和磁盘数据库在索引查找上的思路完全不同。磁盘数据库的慢在IO，内存常驻后，真正的慢开始转移到内存访问的延迟，也就是cache miss。如果一次点查要访问三层B+树，每一层都是一个随机的内存跳转，而内存访问一次约100ns，一次查询在这个环节就能吃掉300ns以上，这在中高并发下是个不小的数字。
常见的优化思路是把B+树内部节点构建成更紧凑的数组形式，尽量让查找过程在连续内存里二分。当数据量允许时，直接把中间层缓存成一条连续的目录数组，使第一层查找几乎变成顺序访问，后面的跳转只要再到叶子页。这样可以把点查从多次随机访存压缩到一次随机访存加一次顺序比较。
如果键的类型是定长整数，还可以到更底层的指令级优化。比较几个字节的值，在x86上可以用SIMD批量完成，这样一次比较能同时覆盖多个候选键。不过这类优化属于锦上添花，要在前面几项都做扎实之后再做。
4. 事务并发控制：从锁等待到死锁处理的全链路选择
并发控制是数据库内核比赛里最核心也最容易翻车的一环。原因很简单——并发控制直接决定你能吃多少CPU的多核红利，同时也决定评测时会不会因为死锁检测和回滚逻辑写得不好而崩溃。这里要分清两类锁：一类是保护内存数据结构（如B+树节点）的latch，另一类是事务之间保证隔离性的lock。把这两者的职责混在一起写，一定会出问题。
4.1 关键取舍：锁粒度越细，读写并行度越高，但开销也越大
以更新操作为例，如果你用一个全局事务锁去串行化所有写事务，实现起来最简单，但高并发下的吞吐会直接塌掉。评测负载里写事务达到一定比例后，这个方案连原版默认实现的尾气都吃不到。实际中至少要做到行级锁或者页级锁。
行级锁的精髓在于把锁信息放到索引记录上，而不是单独维护一张大哈希表。你往B+树的叶子节点里加上锁位图或者锁指针，Update时先定位到具体行，再尝试获取该行的写锁，读请求不受影响。如果同一行被并发更新，后到的事务会进入等待队列，而不是立刻重试或者报错。
锁等待还需要处理超时。真实数据库一般由InnoDB提供锁等待超时参数，比赛实现也应该有类似的机制，否则一个事务占着行锁长期不释放，后面所有事务全堵住，评测会直接把这种场景判负。
4.2 latch怎么处理：自旋锁、互斥锁还是原子变量
latch是保护索引内部结构一致性的短临界区锁。它的特点是持锁时间极短——通常只是一次节点指针替换或者一个标记位翻转。对这种锁使用操作系统提供的互斥锁，经常会发生线程被挂起再唤醒，开销反而比锁内代码本身高一个数量级。
更合适的做法是自旋锁。临界区内的操作通常几条指令就能完成，让等待线程原地自旋几十纳秒，比线程切换划算得多。自旋时要使用带backoff的策略：第一次获取失败后pause几个周期，再失败次数变多则可以让出CPU，避免无意义空转。
写B+树时，节点分裂和父节点更新涉及多级结构，很多人会直接加一把全局树锁，这一下就把读并发彻底锁死了。推荐的方案是读写锁或者读写锁加copy-on-write：读路径加共享锁，所有读操作并行执行；只有当写操作真正要修改结构时才升级为独占锁。更极致的前提下，可以在读路径完全不加锁，靠原子版本号判断读到的是不是一个稳定版本，如果不是就重试。这个方案在只读快照查询多的评测模型下收益惊人。
4.3 死锁处理：检测回滚和死锁预防怎么选
锁粒度细化后，死锁就不可避免。两个事务各拿一把行锁再互相等对方的锁，如果不加干预，两边都会一直等下去。处理死锁有两种主流方案：死锁检测和死锁预防。
死锁检测的做法是维护一份“事务等待图”，后台线程定期检测图中是否存在环，发现环就选择代价最小的事务回滚释放锁。工程上实现等待图比较繁琐，但行为可控，真实数据库大多数用这种方式。死锁预防的做法则是从源头上分配优先级。比如每个事务启动时获取一个时间戳，锁冲突时只允许老事务等新事务，新事务发现对方比自己老，立即放弃重来。这套策略对“短事务多、冲突率高”的评测负载很友好，因为回滚成本低，重来一次往往很快就成功。
个人建议在比赛阶段做“超时回滚加有限等待图检测”的组合：短超时兜底，每秒扫一次锁等待队列，发现环立刻挑回滚代价最小的事务回滚。不要一开始就追求特别复杂的图算法，Wait-for Graph有环判断基本够用。
4.4 别忽略MVCC这个读优化利器
如果你的引擎需要支持可重复读这种隔离级别，MVCC（多版本并发控制）几乎是绕不开的方案。它把历史版本链挂在索引记录上，事务读数据时按自己的活跃事务列表找到可见版本，写操作只追加新版本，因此读不阻塞写、写不阻塞读。
MVCC的实现复杂度主要在两处。第一处是版本链的回收——如果旧版本链长到不可控，读操作要沿着链表查很多版本才能找到可见数据。回收时机通常依赖事务系统判断“当前没有更早的活动事务了”。第二处是undo日志的维护，它要支持事务回滚时把数据恢复到旧版本。如果赛题不要求可重复读，只是已提交读，MVCC的设计可以轻很多，但仍建议保留基本的读写分离能力，这对读多写少的评测负载有质的提升。
5. 日志与提交链条上的隐形成本，组提交能带来翻倍收益
很多人把优化重点放在索引和锁上，日志却成了被遗忘的角落。实际上，在高并发写压力下，日志提交往往是真正的吞吐咽喉。数据库的WAL（预写日志）原则要求：事务提交前，重做日志必须落盘。fsync一次磁盘操作通常要几毫秒，如果每个事务提交都单独触发一次fsync，你这个数据库的每秒提交数上限就被死死摁在几百左右。
5.1 redo log组提交：把多个提交合并成一次写盘
组提交的原理很朴素：让多个并发提交的事务共享一次日志落盘。事务A先进入提交阶段，开始写日志并准备fsync；事务B和C也在这段时间内进入提交阶段，但看到A正在准备写盘，就不再重复触发fsync，只需要等待A的这次fsync完成，随后三个事务统一返回提交成功。
实现组提交要在事务提交入口维护一个提交队列，队列头节点作为leader负责刷盘，其余事务作为follower排队等待结果。这种模式要求日志缓冲区的内容一次性批量写入日志文件，而不是每个事务写一条触发一次IO。调整日志缓冲区的容量，让它能容纳高峰期并发事务产生的所有log record，组提交的效率会更高。
5.2 数据文件写回与双写问题
日志解决了崩溃恢复，但数据页本身的写入策略同样需要权衡。脏页不能一直留在内存里不写回，否则崩溃后必须通过redo重放所有日志，恢复时间会非常长。常见的做法是后台线程按水位异步刷脏页，需要时再做增量检查点。检查点太频繁会带来额外写放大，但能缩短恢复时间；检查点太稀疏则重放日志很长。评测通常更关注运行期吞吐，建议把检查点频率设置得保守一些，优先保证写入路径不被刷脏拖慢。
另一个容易忽略的问题是“部分页写入”。如果磁盘在写入16KB的页时只成功写了一半就断电，这个页处于物理损坏状态，仅靠redo日志无法修复，因为日志里存的可能是旧页还是新页，MySQL周边习惯用双写缓冲来处理。如果你的引擎允许关闭崩溃一致性，或者说评测机模拟掉电时使用O_DIRECT模式，可以省掉双写缓冲。否则就一定要维护一个双写缓冲区，先把整页拷贝到连续空间，再真正写回数据文件。
5.3 不刷盘、半刷盘、全刷盘：不同可靠性档位的成绩差异
比赛环境里通常不会真的断电，但评测代码可能会在某一时刻主动停库检查数据文件完整性。因此你要知道自己能关闭哪些保护措施，同时又不越过评测的底线。
我常用的做法是把可靠性档位做成可配置：出厂默认全刷盘，保证每次提交日志都fsync；比赛适配档位可以改成每秒刷一次日志缓冲。如果评测负载是长时间跑分，中途完全不kill进程，持久化压力较小，用放宽的刷盘策略跑出来的成绩会明显高于全刷盘。但前提是保留一份完整可靠模式用于正确性核验，千万不要让不安全配置混入提交版本。
6. 防止优化把自己优化挂了：提交前的正确性验收清单
比赛进行到后半段，队伍里往往是另一番景象：性能改上去了，但时不时会冒出一个偶发的数据不一致，或者在高并发场景下进程直接崩溃。这种问题的排查成本，比做性能优化还要高。关键原因在于性能优化本质上是在拿正确性做抵押，每一处减少锁、推迟刷盘、压缩信息的改动，都有可能在边界场景里变成一颗定时炸弹。
6.1 并发随机校验器：让bug自己现形
想有效验证并发正确性，靠手写几个固定的测试用例远远不够。我在比赛阶段会写一个随机校验器：启动多个线程，每个线程独立执行一系列数据库操作，包括新增、修改、删除和回滚。所有操作都被记录成一条逻辑日志，期望值是预先计算好的。每个事务结束后或者最终结束时，通过全表扫描比对实际值与期望值，找出所有不一致。
这种随机校验器需要保证覆盖关键边界：唯一键冲突、批量删除后重新插入相同主键、长事务中穿插其他事务的提交、同一行被多个连接反复更新。把并发度调高，跑上几分钟，很多问题就会现出原形。如果发现问题，要优先构造最小复现用例，再配合日志断点去查。
6.2 崩溃恢复测试：不能只测优雅停库
只通过kill命令让进程正常退出并检查数据，测不到崩溃恢复的逻辑。评测可能在你写完一批事务、缓冲池还没有完全刷盘的瞬间直接断电。这时候引擎重启后必须通过redo日志把已提交但未写回数据文件的事务重放出来，把未提交事务的修改回滚干净。
在本地验证时我会用systemd或脚本直接kill -9主进程，模拟断电，然后重启检查数据。这个测试要连跑多轮，尤其是刚好在日志写了一半、页写了一半的瞬间被中断。别嫌麻烦，崩溃恢复逻辑的bug往往只在这种时刻出现。
6.3 不要只开O2，sanitizer能帮你省三天排查时间
比赛后期，内存和线程相关的bug会开始集中爆发。直接在编译时开启AddressSanitizer和ThreadSanitizer成本很低效果却很好。ASan专门查越界、释放后使用、内存泄漏；TSan查数据竞争。很多偶现随机的并发问题在TSan下几乎几秒钟就暴露。
编译大致这样加：
bash复制cmake -DCMAKE_CXX_FLAGS="-fsanitize=thread -g -O1"
注意TSan在O2下可能出现误报，建议用O1跑。速度会慢一些，但正确性验证阶段慢一点没关系。每次优化合入前，先跑一次全量随机校验加崩溃恢复测试，再跑一轮性能对比，没有回归才允许进主分支。
6.4 备份一份“安全配置”的救急预案
比赛最后一天容易心态失衡。如果主分支在临界时刻发现严重问题，而临时修复的代价太高，最好的策略不是硬撑，而是回退到一个稳妥的版本。因此我建议从第一天就保持一个“全功能正确但性能平庸”的tag，每完成一个阶段性的正确性验收就提交一个快照版本。最后提交前，把这个快照版本的代码也准备好，万一主力优化版本有致命bug，你还可以退回去保住下限。
我自己的经验是，这类比赛最遗憾的不是优化没做到极致，而是明明功能完好、跑分也靠谱的版本，因为最后一天的错误修改把自己毁了。规范提交、频繁验证、保存每个里程碑的干净版本，是比较持久的团队竞争力。
最后再分享一个习惯。每次我改动锁、索引或者日志相关路径，都会先跑一次优化前的压测存档，再跑一次优化后的压测进行AB对比，同时把随机校验器挂在后台跑。这样任何性能回退或者正确性回归都能在第一时间暴露，而不是等到几天后通过一道诡异用例才追查。如果你现在正处于比赛后半段，记住把崩溃恢复验证多跑几轮，别觉得这一步多余，它救过我很多次。祝大家都能在性能与正确性之间找到自己的甜点。