下面哪种场景会产生大量碎片 SSTable，拖慢查询性能？（）
A. 低频少量插入，每日正常大合并
B. 高频更新删除，长期未执行 Major 合并
C. 仅只读查询业务，无写入操作
D. 合理分区 + 本地索引设计的平稳业务
1 个赞
正确答案是：B. 高频更新删除，长期未执行 Major 合并
解析：
这道题考察的是 OceanBase 基于 LSM-Tree 架构的存储引擎特性以及“读放大”问题。
- B. 高频更新删除，长期未执行 Major 合并（正确）：在 LSM-Tree 架构中，数据的更新和删除操作在合并（Major Compaction）之前，只是在内存或增量 SSTable 中追加写入一条逻辑标记（如 Delete 标记或新版本数据），而不会直接修改原有的基线 SSTable 数据。如果业务存在高频的插入、更新和删除，且长时间未触发大合并，系统中就会堆积大量的增量 SSTable 和带有删除标记的“墓碑”记录。这会导致查询时需要扫描大量无效的物理行（即“Buffer 表效应”或 Queuing 表效应），产生严重的读放大，从而大幅拖慢查询性能。
- A. 低频少量插入，每日正常大合并（错误）：正常的每日大合并会将增量数据与基线数据进行归并，清理掉过期数据和删除标记，生成紧凑的新 SSTable，这正是解决碎片和读放大问题的机制。
- C. 仅只读查询业务，无写入操作（错误）：纯只读业务不会产生新的增量数据，也不会产生删除标记，因此不会导致 SSTable 碎片化。
- D. 合理分区 + 本地索引设计的平稳业务（错误）：平稳的业务负载配合合理的表结构设计，系统能够正常进行转储和合并，不会产生大量碎片。