数据库领域有一个长期困扰业界的难题。当你提交一个几十KB的事务时，数据库系统能够快速完成。但当这个事务膨胀到几GB甚至1TB时，提交和回滚的时间往往会随着数据量的增长而线性上升。一个250万行的批量导入，可能需要数小时才能完成提交。一个未提交完就宕机的1TB事务，可以让数据库停摆数小时甚至更久。
OceanBase团队在SIGMOD 2025上发表的论文MaLT: A Framework for Managing Large Transactions in OceanBase，正是为了解决这一难题。该论文提出了一个名为MaLT的框架，首次在LSM-tree存储引擎中直接管理大事务，实现了与事务大小无关的常数时间提交、回滚和恢复。本文将深入解读MaLT的核心设计、技术原理与性能表现。
一、大事务的代价：传统LSM-tree数据库的困境
1.1 什么是大事务
大事务不是几十行的转账操作，而是单次几十万到几百万行的批量写入。金融系统的日终跑批、数据导入等场景，一次提交250万行，数据量从几百GB到1TB是常态。这些事务的共同特点是未提交数据量远超内存容量。
大事务对数据库系统的挑战在于：事务提交前，所有改动处于未提交状态，既不能对其他事务可见，又必须随时能够回滚。如何存放这批未提交数据，成为LSM-tree数据库面临的核心难题。
1.2 现有方案的两种路径及其上限
现有LSM-tree数据库处理大事务主要有两种做法，各自存在明显的上限。
第一种是全部放在内存中。采用Percolator模型的一类系统，将所有未提交数据保存在内存中。这种方案实现简单，但事务大小受限于可用内存。一旦事务超过内存容量，就会触发OOM，导致系统崩溃。
第二种是允许落盘。以RocksDB为代表的系统，采用steal策略允许未提交数据写入磁盘。代价是提交前必须保留整个WAL不能回收，事务大小受日志容量限制。当日志文件被撑满时，系统同样无法继续执行。
这两种方案的共同问题是：LSM-tree被当作一个黑盒的key-value存储，存储引擎不感知事务语义。提交一个事务意味着把事务改过的每一行重写一遍，将版本号更新为提交版本，回滚则要把它们覆盖回去。由于SSTable是不可变的，这些重写只能作为新的KV追加。结果是：提交和回滚的额外I/O恰好等于事务本身的大小，而且因为引擎看不到事务语义，这部分开销无法优化。
1.3 崩溃恢复的代价
除了提交和回滚，大事务还带来了另一个棘手问题：崩溃恢复。传统的ARIES恢复分为redo和undo两个阶段。undo阶段需要逐行抹掉未完成事务的改动，耗时与事务的大小成正比。一个未提交完就宕机的1TB事务，undo操作可能需要数小时，期间相关行锁一直持有，数据库对外不可用。
现有方法虽然提出了消除B+树数据库大事务恢复问题的方案，但它们不适用于LSM-tree系统，因为LSM-tree禁止对SSTable进行原地更新。无论是redo还是undo阶段，都依赖于活跃事务和已终结事务的状态信息，因此管理事务状态的持久化变得至关重要。
二、MaLT的设计思想：拆掉存储引擎的黑盒
2.1 核心洞察
MaLT的核心洞察非常简单：不再把LSM-tree当成只认key和value的存储层，而是让它理解事务。通过把事务状态和事务信息从存储引擎外部搬进LSM-tree内部，MaLT在源头上解决了大事务的提交、回滚和恢复效率问题。
MaLT分两步做这件事：给LSM-tree配两张事务表，再把事务信息嵌进每一行。
2.2 TCT与TDT：两张事务表
TCT负责管理活跃事务。每个执行中的事务，其上下文都记录在TCT中：事务状态、提交版本，以及一个操作索引，按执行顺序记下该事务改过哪些行。TCT常驻内存，只在checkpoint时按LSM-tree的flush流程落盘一次，正常运行期间不访问磁盘。
TDT负责管理已终结事务。事务一旦提交或中止，其事务数据从TCT移交给TDT。关键之处是TDT本身也是一棵LSM-tree（内存的TMemTable加磁盘的TSSTable），因此它继承了LSM-tree的两个特性：顺序写入，以及由后台compaction周期性回收过期数据。事务数据在TCT和TDT之间实现zero-copy移交，不复制数据，只转移引用。
仅这两张表就解决了未提交数据放不下这个问题。未提交改动不必全留内存（TCT只存上下文），也不必锁住WAL。行数据落在LSM-tree里，状态由TCT和TDT在外部追踪。事务大小不再受内存或日志限制。
2.3 事务信息嵌进行里
LSM-tree本身就是多版本的，每行自带TxID和版本号。MaLT在此基础上给每行再加三个字段：
Exist字段表示该行是否存在，用于区分插入与删除。Lock字段表示该行是否被某事务持有行锁。Max_Version字段表示该行已提交的最大版本号。
这三个字段让并发控制在内存里就能完成。主键冲突查Exist，行锁冲突查Lock，丢失更新查Max_Version，都不需要回磁盘读原始行。更重要的是，LSM-tree现在能区分哪些版本属于哪个事务、那个事务是否已终结。黑盒KV没有这个信息，只能在提交时一次付清重写开销。
三、常数时间提交与回滚
3.1 提交的路径
事务执行时，改动以未提交版本写入MemTable，每个版本带事务的TxID。TCT记录事务的上下文，操作索引按顺序记下它改过的行。
提交时，把LSM-tree当KV存储的系统必须把这几十万行逐行重写，将版本号改成提交版本，开销与事务大小成正比。MaLT不重写。它在TCT中把事务标记为已提交、记下提交SCN，把事务数据移交给TDT，提交即完成。未提交版本留在原处，由compaction处理：合并各层数据时，对每个未提交版本查一次它所属事务在TDT中的状态。已提交则回填版本号，已中止则丢弃。
改动量不超过阈值的小事务走另一条路：直接用操作索引在MemTable中就地backfill或undo，不涉及TDT和compaction。
3.2 回滚走同一条路径
回滚只改TDT中的状态，未提交版本同样等下一次compaction清除。提交和回滚因此与事务大小无关。事务改了1MB还是1TB，这一步都只是改几个状态、移交一次引用。
3.3 实测数据
论文中的测试数据显示了这种设计的威力。在Sysbench测试中，把单个事务从1GB逐步增大到1TB，分别测量提交和回滚耗时。MaLT的两条曲线基本保持水平，而其他系统随事务增大而急剧上升。MySQL在1TB量级的回滚达到小时级，开销主要来自逐页undo和binlog同步。一个商业分布式数据库在事务超过50GB后直接报错失败，另一个虽然能完成但处理大事务效率很低。
四、无undo的崩溃恢复
4.1 重新设计恢复路径
假设一个事务还没提交完数据库就宕机了。传统ARIES恢复需要跑redo和undo，undo负责逐行抹掉未提交改动，耗时与事务大小成正比。
MaLT不跑undo。redo照常进行：先用checkpoint持久化的TCT恢复事务上下文，再从checkpoint之后重放日志。日志是物理逻辑日志，每行带SCN，重放可以乱序并行。重放某条记录时，比较它的SCN和目标行当前版本的SCN，决定是否应用，不必严格按序。redo结束，所有活跃事务回到宕机前的状态。
4.2 undo被省去
未提交版本不需要在恢复时清理。之后读到它们时，查一次TDT中对应事务的状态，已中止就跳过该版本。回滚清理同样推迟到后续compaction。恢复耗时因此与事务大小无关，状态在TDT中可见，读取时即可判定，不需要停下来逐行undo、并在此期间持有锁。
4.3 恢复测试数据
在崩溃恢复测试中，MaLT在不同事务大小下保持稳定恢复时间，而其他系统的恢复时间随事务增大线性上升。
五、读写性能优化
5.1 版本边界与读取剪枝
事务信息嵌在数据里之后，读和写各省掉一次磁盘I/O。MemTable和每个SSTable都带版本边界，一段SCN范围和一段RowKey范围。一次带快照版本的读，先用边界与之相交的数据集确定下界，再取数据。边界不相交的整块跳过，不必读进去才发现没有目标版本。
5.2 事务数据缓存
为进一步降低读取事务数据本身的开销，MaLT给TDT加了两级的事务数据缓存。查询级的小缓存应对一次查询内对同一事务数据的重复读，LRU大缓存应对跨查询的热点数据。
5.3 写入路径优化
写路径上的主键冲突、行锁、丢失更新这三种检测，传统上都要把对应行从磁盘读出来确认。MaLT直接查行内的Exist、Lock、Max_Version，这些写路径不再访问磁盘。
5.4 TPC-C测试结果
在TPC-C基准测试中，开启这些优化的MaLT比把LSM-tree当黑盒KV的版本tpmC高约23%，平均延迟低约22%。测试机器是64核Intel Xeon Platinum 8369B、400GB内存，对照组包括MySQL 8.0和两个商业分布式数据库。
在大事务导入场景中，模拟金融批量导入250万行数据，端到端耗时从11778秒降到8966秒，快了23.9%。
六、其他SIGMOD 2025入选论文
6.1 OceanBase六篇论文入选
OceanBase团队在SIGMOD 2025上共有6篇论文被接收，创下该团队在该顶会中被收录论文数量的新高。除MaLT外，还涵盖了现代存储架构、差分隐私、预测查询执行等多个前沿方向。
OLTP Engines on Modern Storage Architectures这篇论文由OceanBase独立发表，介绍了利用持久内存、NVMe SSDs、CXL等现代存储架构增强OLTP引擎的技术，探讨了新兴存储硬件带来的机遇与挑战。
Mitigating the Impedance Mismatch between Prediction Query Execution and DatabaseEngine提出了IMBridge原型系统，通过在数据库引擎中采用预测感知算子，利用推理上下文重用缓存和批量感知函数调用，在OceanBase上实现了平均71.4倍的预测查询执行效率提升。
6.2 国际学术界的认可
ACM SIGMOD是数据库领域历史最悠久、最具权威性的国际顶级学术会议之一，代表着全球数据库研究的最高水平。OceanBase六篇论文入选，不仅是团队在数据库技术研究领域持续深耕的体现，更标志着其在分布式数据库核心技术和前沿方向上的创新成果获得了国际学术界的广泛认可。
总结
MaLT的核心价值在于它将事务状态和事务信息从存储引擎外部搬进LSM-tree内部。这一设计带来了三个层面的根本改善。提交和回滚从与事务大小成正比变为常数时间，恢复过程不再需要逐行undo，读写路径各少一次磁盘访问。
在TPC-C测试中，MaLT比将LSM-tree当黑盒KV使用的版本提升了23%的tpmC，平均延迟降低22%。在大事务导入场景中，端到端耗时从11778秒降低到8966秒。这些数据来自OceanBase 4.x的生产环境，已服务上千家客户。
OceanBase通过MaLT证明了：在LSM-tree架构上管理大事务，不需要在内存限制、日志容量和恢复效率之间做艰难的取舍。把事务语义带入存储引擎内部，而不是把它当作黑盒来处理，是解决大事务问题的一条可行路径。这也是SIGMOD 2025选择接收这篇论文的重要原因。