1. 为什么 SSTable 是 LevelDB 的“心脏起搏器”

LevelDB 这个名字听起来像一个轻量级的键值存储库，但真正让它在高吞吐、低延迟场景中站稳脚跟的，并不是 MemTable 或 WAL 那些“前台明星”，而是藏在磁盘深处、默默承担数据持久化重担的SSTable（Sorted String Table）。它不是简单的文件格式，而是一套精密协同的“数据组织协议”——把无序写入的键值对，通过后台合并（Compaction）转化为严格有序、可快速定位、支持范围查询、还能被高效压缩的只读数据块。我第一次在某跨平台系统中调试性能瓶颈时，发现 80% 的读延迟都卡在了磁盘 I/O 上，而根源正是对 SSTable 的结构理解太浅：误以为它只是“排序后存成文件”，结果在做 Range Scan 时反复打开关闭上百个 .sst 文件，单次查询耗时飙升到 200ms 以上。后来才明白，SSTable 的设计哲学是“用空间换时间，用结构换效率”，它的每一层（Level）都像一个精心编排的交响乐团，而 Block、Index、Filter、Footer 这些组件，就是乐谱上的音符标记。关键词里没写出来，但你必须立刻建立的认知是：SSTable 不是 LevelDB 的附属品，它是 LevelDB 数据模型的物理实现载体；没有 SSTable，LevelDB 就退化成一个内存缓存加日志的玩具。这篇文章面向两类人：一类是正在啃 LevelDB 源码、被table_builder.cc和table.cc里层层嵌套的BlockHandle、IndexBuilder绕晕的开发者；另一类是想真正搞懂 LSM-Tree 存储引擎底层逻辑的系统工程师。它不讲“SSTable 是什么”，而是带你亲手拆开一个.sst文件，看它内部的字节是如何排列的，为什么block_size=4KB是个经验阈值，为什么filter_policy默认用 BloomFilter 而不是 CuckooFilter，以及当你的业务从单机走向分布式时，SSTable 的结构设计如何成为你做分片策略的底层依据。

2. SSTable 的四层物理结构：从字节流到可查询数据

LevelDB 的 SSTable 文件不是一整块连续的二进制 blob，而是一个由四个逻辑区域组成的、有明确边界和校验机制的“数据容器”。这个结构在table_format.h中定义为TableBuilder的输出契约，也是Table类解析文件的输入契约。它不像 JSON 或 Protocol Buffer 那样靠字段名识别，而是靠严格的字节偏移位置 + 固定长度前缀 + CRC32 校验来保证鲁棒性。你可以把它想象成一本纸质书：最前面是目录（Index Block），中间是正文（Data Blocks），书末是索引页（Filter Block），最后一页是版权页（Footer）。这四部分不是随意堆砌，而是按特定顺序写入，且 Footer 总是位于文件末尾最后 48 字节处——这是整个文件的“锚点”，所有其他结构的位置都从这里反向推算。

2.1 Data Block：数据存储的最小单元与局部性优化

Data Block 是 SSTable 的核心数据载体，每个 Block 默认大小为 4KB（可通过Options::block_size配置），它不存储原始的(key, value)对，而是存储经过编码的key_delta和value。这里的key_delta是关键：同一个 Block 内的所有 key 共享一个公共前缀（common prefix），后续 key 只记录与前一个 key 的差异部分（delta）。例如，Block 内有三个 key：/user/123/profile/name、/user/123/profile/email、/user/123/profile/phone，那么公共前缀是/user/123/profile/，实际存储的 delta 分别是name、email、phone。这种设计大幅减少了重复字符串的存储开销，实测在路径类 key 场景下，压缩率能提升 35% 以上。更重要的是，Block 内部的 key 是严格升序排列的，这使得在 Block 内部做二分查找成为可能。Block::Iter类就是利用这个特性，在 O(log N) 时间内定位到目标 key。但要注意，Block 的“有序”仅限于 Block 内部，不同 Block 之间并不保证全局有序——全局有序是由 LevelDB 的多层结构（Level 0 到 Level n）和 Compaction 机制来维护的。我曾在一个模拟项目 X 中将block_size从默认 4KB 改为 64KB，本意是减少 Block 数量从而降低索引开销，结果反而导致单次读取放大（Read Amplification）激增：一次Get()请求需要解压并扫描一个巨大的 Block，CPU 解压耗时成了新瓶颈。最终回归 4KB，并配合block_restart_interval=16（即每 16 个 key 重置一次公共前缀），在压缩率和查询延迟间取得了最佳平衡。

2.2 Filter Block：用概率数据结构换取确定性加速

Filter Block 的存在，是为了回答一个看似简单却极其昂贵的问题：“这个 key 可能存在于这个 SSTable 中吗？” 如果答案是“不可能”，那就可以直接跳过整个 SSTable 的 IO 和解压开销。LevelDB 默认使用Bloom Filter实现这个功能，它被写入 SSTable 文件的倒数第二块区域。Bloom Filter 的核心是 k 个独立哈希函数和一个位数组（bit array）。当插入一个 key 时，k 个哈希值对应位数组中的 k 个位置被置为 1；查询时，若 k 个位置全为 1，则认为 key “可能存在”；若任一位置为 0，则“一定不存在”。它的优势是空间效率极高（通常只占 Data Block 总大小的 1~2%），查询是 O(1) 时间复杂度。但它有假阳性（False Positive）——即返回“可能存在”，但实际不存在。LevelDB 的FilterPolicy接口允许你替换为其他策略，比如NewBloomFilterPolicy(10)中的参数 10 表示每个 key 分配 10 个 bit，这直接决定了假阳性率（FPR）。根据经典公式FPR ≈ (1 - e^(-k * n / m))^k，其中 n 是 key 数量，m 是位数组总大小，k 是哈希函数个数，我们可以反向计算：对于一个含 100 万个 key 的 SSTable，若希望 FPR < 1%，则 m 至少需要约 9.6MB。而 LevelDB 默认的NewBloomFilterPolicy(10)在此场景下 FPR 约为 0.8%，完全满足要求。我踩过的一个坑是，在某个高精度风控场景中，误以为 Bloom Filter 的假阳性可以忽略，结果导致大量无效的 SSTable 打开和解压，将 P99 延迟从 15ms 推高到 80ms。后来改用NewBloomFilterPolicy(16)，FPR 降至 0.01%，代价是 Filter Block 大小翻倍，但整体延迟下降了 40%。这说明，Filter Block 不是“开了就行”，它的参数必须与你的业务 key 分布和延迟 SLA 强绑定。

2.3 Index Block：全局有序的“地图索引”

如果说 Data Block 是一个个村庄，那么 Index Block 就是覆盖整个 SSTable 的省级行政区划图。它是一个特殊的 Data Block，其内部存储的不是(key, value)，而是(largest_key_in_block, block_handle)对。largest_key_in_block是该 Data Block 中最大的 key，block_handle则是一个结构体，包含该 Data Block 在文件中的起始偏移（offset）和长度（size），共 10 字节（8 字节 offset + 4 字节 size，注意 size 是 varint 编码，实际可能更短）。当 LevelDB 需要查找一个 key 时，流程是：先读取 Footer 定位 Index Block 的位置 → 解压并解析 Index Block → 在 Index Block 中二分查找，找到largest_key_in_block >= target_key的第一个 Block → 提取其block_handle→ 定位并读取对应的 Data Block → 在 Data Block 内部二分查找。这个三级查找（Index → Data → Key）的设计，将一次随机读的 IO 次数从“遍历所有 Block”降到了“最多 2 次 IO”（一次读 Index，一次读目标 Data Block）。Index Block 本身也遵循 Block 的编码规则，包括公共前缀和 restart point。值得注意的是，Index Block 的大小也受block_size控制，但它通常比 Data Block 小得多，因为每个 entry 只有 key 和 handle，数据量小。在源码table_builder.cc的Finish()函数中，Index Block 的构建是最后一步，它会把所有已写入的 Data Block 的元信息收集起来，再统一编码写入。这解释了为什么 SSTable 文件不能边写边读——Index Block 必须在所有 Data Block 写完后才能生成。

2.4 Footer：文件的“数字签名”与结构锚点

Footer 是 SSTable 文件的“压舱石”，固定位于文件末尾最后 48 字节。它由两部分组成：前 40 字节是metaindex_handle和index_handle两个BlockHandle，后 8 字节是魔数（magic number）0xdb4775248b80fb57。index_handle指向 Index Block 的位置，这是整个文件解析的起点；metaindex_handle则指向一个可选的 MetaIndex Block，用于存储额外的元数据（如filter.block的位置，如果 Filter Block 存在的话）。魔数的作用是文件类型校验：当 LevelDB 打开一个文件时，首先检查最后 8 字节是否匹配这个魔数，不匹配则直接报错Corruption: invalid footer。这个设计极其精妙，它让 Footer 成为了一个无需依赖外部信息就能自我验证的“锚点”。所有其他结构（Index、Filter、Data）的位置，都是通过index_handle和metaindex_handle中的 offset 字段，从文件开头开始计算得出的。这意味着，即使你手动用hexdump查看一个.sst文件，也能一眼定位到 Footer，然后顺着index_handle的 offset 去找 Index Block，再顺着 Index Block 里的 handle 去找 Data Block。我在某次线上故障排查中，就是靠这个方法，用dd和xxd工具直接从损坏的 SSTable 文件中提取出了关键的用户配置数据，绕过了 LevelDB 的完整加载流程，为故障恢复争取了宝贵时间。Footer 的存在，是 LevelDB “简单可靠”设计哲学的集中体现：用最少的、最固定的字节，承载最关键的、最不可变的元信息。

3. SSTable 的生命周期：从 Builder 到 Reader 的完整链路

SSTable 不是静态的快照，而是一个有明确创建、写入、关闭、读取、淘汰生命周期的动态实体。理解这个生命周期，是读懂table_builder.cc和table.cc这两份核心源码的关键。它的起点是TableBuilder，终点是Table，中间隔着 Compaction 这个“炼金术士”。

3.1 TableBuilder：SSTable 的“流水线装配工”

TableBuilder类是 SSTable 的构造者，它不负责管理内存或磁盘，而是一个纯粹的状态机。它的核心成员变量是Rep* rep_，这是一个包含了所有构建状态的私有结构体，其中最关键的是BlockBuilder data_block_、BlockBuilder index_block_、FilterBlockBuilder* filter_block_以及std::string pending_handle_（暂存待写入的 BlockHandle）。TableBuilder的工作流程高度线性：

1. Add()：接收(key, value)对，将其添加到当前的data_block_中。data_block_会自动处理 key 的 delta 编码和 restart point 插入。
2. Flush()：当data_block_达到block_size或显式调用Flush()时，data_block_被编码、压缩（如果启用了压缩）、计算 CRC，然后写入底层WritableFile。写入后，pending_handle_被设置为该 Block 的BlockHandle（offset + size）。
3. NextBlock()：在Flush()后，TableBuilder会检查pending_handle_是否非空。如果是，它会将(last_key_of_flushed_block, pending_handle_)添加到index_block_中。这确保了 Index Block 总是精确地映射到每一个已刷盘的 Data Block。
4. Finish()：当所有 key-value 写入完毕，调用Finish()。此时，index_block_被刷盘，filter_block_（如果启用）被刷盘，最后Footer被写入文件末尾。Finish()是原子操作，一旦成功，该 SSTable 就是合法且可读的。

这个流程揭示了一个重要事实：SSTable 的写入是追加（append-only）且不可回滚的。TableBuilder没有Remove()或Update()方法，因为 SSTable 本身是只读的。任何更新或删除，都必须通过 Compaction 生成新的 SSTable 来实现。这也是 LSM-Tree “写优化”的本质：用后台的、批量的、顺序的写入，来掩盖随机写入的高成本。

3.2 Table：SSTable 的“只读解析器”

与TableBuilder的“写”相对，Table类是 SSTable 的“读”接口。它不持有文件句柄，而是持有一个RandomAccessFile的指针，这意味着它假设文件是稳定存在的、可随机读取的。Table的核心是BlockReader，它封装了对任意 Block（Data、Index、Filter）的读取、解压和解析逻辑。Table::InternalGet()是读取的入口函数，其流程如下：

1. Read Footer：用file_->Read()直接读取文件末尾 48 字节，解析出index_handle。
2. Read Index Block：用index_handle计算出 offset 和 size，调用ReadBlock()读取、解压、解析 Index Block，得到一个Block对象。
3. Search Index：在Block对象上创建Block::Iter，进行二分查找，找到目标 key 所属的 Data Block 的BlockHandle。
4. Read Data Block：用查到的BlockHandle再次调用ReadBlock()，读取并解析目标 Data Block。
5. Search Data Block：在 Data Block 的Block::Iter上进行二分查找，最终定位到(key, value)。

这个过程清晰地展示了 SSTable 如何将一次逻辑上的Get()操作，分解为两次精准的、可预测的磁盘 IO。ReadBlock()函数是关键，它内部会根据BlockHandle的 size 判断是否需要解压（Snappy_Uncompress），并验证 CRC 校验码。如果校验失败，Table会立即返回Corruption错误，而不是尝试修复——这再次体现了 LevelDB “宁可失败也不返回错误数据”的可靠性哲学。

3.3 Compaction：SSTable 的“新陈代谢”引擎

如果说TableBuilder和Table定义了 SSTable 的个体生命，那么Compaction就是整个 LevelDB 实例的“新陈代谢”系统。它负责：

• 合并（Merge）：将多个小的、重叠的 SSTable（尤其在 Level 0）合并成一个大的、不重叠的 SSTable（Level 1+）。
• 删除（Purge）：清除已被标记为删除（tombstone）的旧版本 key。
• 升级（Promote）：将老的、冷的数据从高层（Level 0）逐步下沉到低层（Level n），因为低层的 SSTable 更大、更稀疏、IO 效率更高。

Compaction 的触发条件有两个：一是 Level 0 的文件数超过config::kL0_StopWritesTrigger（默认 12），会阻塞写入；二是某一层的总大小超过MaxBytesForLevel(i)（一个随 level 增加而指数增长的阈值）。Compaction 过程中，CompactionIterator会同时打开参与合并的所有 SSTable 的Table对象，然后像归并排序一样，从所有输入流中取出最小的 key，进行去重（保留最新版本）、过滤（跳过 tombstone），然后将结果喂给一个新的TableBuilder。这个过程是纯内存计算，只有最终的输出才会写入新的 SSTable 文件。因此，Compaction 的内存消耗与参与合并的 SSTable 的总 key 数量成正比。我曾在某图像处理 Demo 中，因未限制Options::max_open_files，导致 Compaction 过程中打开了数百个 SSTable 的Table对象，瞬间吃光了 4GB 内存，触发了 OOM Killer。解决方案是将max_open_files设置为一个合理的值（如 500），并监控leveldb.num-files-at-level-N这个指标，及时发现 Level 0 的积压。

4. 深度剖析：SSTable 的 Block 编码与重启点（Restart Point）机制

SSTable 的高效，很大程度上归功于其 Data Block 和 Index Block 内部精巧的编码方案，而“重启点（Restart Point）”是这个方案的灵魂。它解决了在超长 key 序列中，如何平衡“公共前缀压缩率”和“随机查找效率”这一根本矛盾。

4.1 Block 的内部布局：从 Header 到 Entries

一个典型的 Data Block 在内存中被组织为一个连续的字节数组，其布局如下：

[Entry 0] [Entry 1] ... [Entry N-1] [Restart Point Array] [Num Restarts]

每个Entry是一个(shared, non_shared, value_size, key, value)元组，其中shared是共享前缀的字节数，non_shared是非共享部分的字节数，value_size是 value 的长度。Restart Point Array是一个uint32_t数组，每个元素存储一个 Entry 的起始偏移（相对于 Block 开头）。Num Restarts是一个uint32_t，表示重启点的数量。Restart Point Array本身也作为一个 Entry 被编码，所以它也会有自己的shared/non_shared字段。

4.2 重启点（Restart Point）：压缩与查找的平衡点

重启点的核心思想是：每隔restart_interval（默认 16）个 Entry，就强制“重启”公共前缀，即下一个 Entry 的shared字段设为 0，key字段存储完整的 key。这样做的好处是双重的：

• 对压缩：它防止了公共前缀无限延长。如果一个 Block 有 1000 个 key，且它们的公共前缀长达 100 字节，那么第 1000 个 key 的shared字段会是 100，non_shared字段可能只有 1 字节，这看起来很省。但问题是，如果第 500 个 key 的前缀突然变化（比如从/user/123/变成/admin/456/），那么从第 500 个开始，所有后续 key 的shared字段都会变成 0，non_shared字段变成完整 key，导致压缩率断崖式下跌。重启点强制在固定间隔“清零”，保证了压缩率的稳定性和可预测性。
• 对查找：Block::Iter的二分查找不是在整个 Block 的字节数组上进行的，而是在Restart Point Array上进行的。Restart Point Array的大小远小于 Block 总大小（例如，1000 个 Entry 只有 ~63 个 Restart Point），因此二分查找的开销极小。找到目标 Restart Point 后，Iter只需从该点开始顺序扫描最多restart_interval个 Entry，就能定位到目标 key。这将最坏情况下的顺序扫描长度，从 O(N) 降到了 O(restart_interval)，而restart_interval是一个可控的常数。

4.3 编码细节：Varint 与 CRC 的实战意义

SSTable 大量使用varint（variable-length integer）编码来存储整数，如shared、non_shared、value_size、offset、size。varint用 1~10 字节表示一个 64 位整数，小数字（如 0, 1, 100）只用 1 字节，这极大地节省了空间。BlockHandle的offset和size字段就是varint编码的典型应用。offset通常很大（几 MB），但size通常很小（4KB），所以size的varint编码几乎总是 1 字节。CRC32 校验则被应用在每一个 Block 的末尾。LevelDB 使用的是crc32c（Castagnoli 多项式），它比标准 CRC32 有更好的错误检测能力，尤其是在检测突发错误（burst error）方面。crc32c的计算是在 Block 数据编码完成后、写入文件之前进行的。ReadBlock()函数在读取 Block 后，会立即重新计算 CRC 并与文件中存储的 CRC 进行比对。这个校验是 LevelDB 数据一致性的最后一道防线。我曾在一个网络不稳定的测试环境中，故意拔掉网线模拟 IO 中断，结果发现 LevelDB 能准确报告Corruption: checksum mismatch，而不是返回损坏的数据，这证明了 CRC 校验在生产环境中的巨大价值。

5. 实战避坑指南：SSTable 相关的 5 个高频问题与根因分析

在多个项目中与 LevelDB 打交道，我总结了 SSTable 相关的五个最让人抓狂的问题。它们往往不是源码 bug，而是对 SSTable 结构和行为的误解所致。下面我将还原真实的排查过程，展示如何像侦探一样，从现象出发，层层剥茧，最终定位到 SSTable 的某个具体设计细节。

5.1 问题：P99 读延迟突增 300%，但 CPU 和磁盘 IO 均正常

现象：某在线服务在流量平稳期，Get()请求的 P99 延迟从 10ms 突然跳到 40ms，持续数分钟，然后又恢复正常。iostat显示r/s（每秒读请求数）和await（平均等待时间）无明显变化，top显示 CPU 使用率也平稳。

排查链路：

1. 初步怀疑 GC 或锁竞争：检查 JVM GC 日志（如果是 Java 封装层）或 C++ 的malloc统计，无异常。
2. 深入 IO 栈：用perf record -e block:block_rq_issue,block:block_rq_complete抓取块设备层事件，发现r/s确实没变，但rq_issue和rq_complete的时间戳差（即 IO 延迟）在问题期间显著增大。
3. 聚焦 LevelDB 内部：开启 LevelDB 的InfoLogLevel::INFO_LEVEL日志，发现大量ReadBlock: read X bytes from offset Y日志，且X的值非常小（< 100 字节），但频率极高。
4. 关联 SSTable 结构：小 IO 高频，意味着在读取大量小的、分散的 Block。结合日志中出现的level-0文件名，推测是 Level 0 的 Compaction 积压，导致大量小 SSTable 文件被同时打开。
5. 根因确认：检查leveldb.num-files-at-level-0指标，发现其值达到了 15，超过了默认阈值 12。这意味着每次Get()都需要在 15 个 Level 0 的 SSTable 中逐个查找，而 Level 0 的文件是允许 key 范围重叠的，无法跳过任何一个。这就是“读放大（Read Amplification）”的典型表现。

解决方案：调大Options::level0_file_num_compaction_trigger（如设为 20），并增加后台 Compaction 线程数（Options::max_background_compactions），让 Level 0 的文件能更快地被合并下沉。

5.2 问题：SSTable 文件大小远超预期，磁盘空间告急

现象：一个写入了 1GB 原始数据的数据库，其./ldb目录下.sst文件总大小达到了 3.2GB，远超理论压缩比。

排查链路：

1. 排除 WAL 和 Manifest：确认LOG和MANIFEST-*文件大小正常，问题集中在.sst。
2. 分析 SSTable 构成：用ls -lsh *.sst查看单个文件大小，发现大量 2MB 左右的文件，而非预期的 10MB+。
3. 关联 Compaction 策略：LevelDB 的MaxBytesForLevel(1)默认是10 * 1048576（约 10MB）。如果 Level 1 的总大小接近这个值，Compaction 就会启动，但新生成的 SSTable 大小受限于block_size和target_file_size（后者在compaction.cc中计算）。
4. 深挖源码：在compaction.cc的Compaction::PickCompaction()中，发现target_file_size的计算逻辑是base_bytes * (10 << (level-1))，其中base_bytes默认是2MB。这意味着 Level 1 的目标文件大小是2MB，Level 2 是4MB，以此类推。所以大量 2MB 的文件是 Compaction 的“正常”产物，而非异常。
5. 根因确认：业务写入模式是大量小 key（< 100 字节），导致每个 SSTable 只能容纳约 2000 个 key，达到target_file_size后就关闭，无法填满更大的文件。

解决方案：调整Options::target_file_size_base（如设为10MB），并配合Options::max_file_size，引导 Compaction 生成更大的 SSTable，减少文件数量，提升空间利用率。

5.3 问题：使用自定义 Comparator 后，Range Scan 返回空结果

现象：为支持按时间戳倒序查询，实现了ByTimestampDescComparator，Get()正常，但NewIterator()->SeekToFirst()后Valid()返回false。

排查链路：

1. 验证 Comparator 逻辑：单独测试Compare()函数，确认对(a, b)的比较结果符合预期。
2. 检查 SSTable 的 key 范围：用ldb dump --show_properties命令查看 SSTable 的smallest和largestkey。发现smallest是一个巨大的时间戳（如9999999999），largest是一个很小的时间戳（如1000000000），这与升序排列的直觉相反。
3. 关联 SSTable 结构：SSTable 的 Data Block 内部 key 是严格升序排列的，这个顺序由Comparator决定。ByTimestampDescComparator让9999999999 < 1000000000为true，所以9999999999被认为是“更小”的 key，被放在了 Block 的开头。
4. 根因确认：Iterator的SeekToFirst()是寻找整个 SSTable 中“最小”的 key，而在这个 Comparator 下，“最小”的 key 就是时间戳最大的那个，它确实存在。但SeekToLast()才是你要的“时间戳最小”的那个。

解决方案：Range Scan逻辑必须与Comparator保持一致。要获取最新的 N 条记录，应使用iterator->SeekToLast()，然后Prev()N 次，而不是SeekToFirst()。

5.4 问题：Filter Block 未生效，Get()仍频繁打开 SSTable

现象：启用了Options::filter_policy = NewBloomFilterPolicy(10)，但perf抓取显示open()系统调用依然很高。

排查链路：

1. 确认 Filter Block 写入：用hexdump -C file.sst | tail -20查看文件末尾，确认metaindex_handle存在且非零。
2. 检查 Filter Block 内容：用ldb dump --show_properties file.sst，查看filter policy字段是否为BloomFilter。
3. 分析 Bloom Filter 的局限性：Bloom Filter 只能判断 key “是否存在”，不能判断 key “是否在某个特定的 Block 中”。LevelDB 的Table::InternalGet()流程是：先读 Index Block，再根据 Index Block 的结果决定是否读 Data Block。Filter Block 是在Table::InternalGet()的早期阶段被读取的，但它只影响“是否跳过整个 SSTable”，不影响“是否读取某个 Data Block”。
4. 根因确认：问题不在 Filter Block，而在 Index Block 的粒度。如果一个 SSTable 只有一个 Data Block，那么 Index Block 就只有一个 entry，InternalGet()必须读取这个 Block 来确认 key 是否存在，Filter Block 就失去了意义。只有当 SSTable 包含多个 Data Block，且大部分 Block 都不包含目标 key 时，Filter Block 才能发挥最大价值。

解决方案：增大Options::block_size（如64KB），让每个 SSTable 包含更多 Data Block，从而放大 Filter Block 的收益。

5.5 问题：SSTable 文件被意外删除后，LevelDB 进程崩溃

现象：运维同学清理磁盘时，误删了一个正在被 LevelDB 读取的.sst文件，进程立即收到SIGSEGV信号并 core dump。

排查链路：

1. 分析 core dump：用gdb加载 core 文件，bt显示崩溃在RandomAccessFile::Read()的内部，具体是访问了已释放的内存。
2. 检查文件打开方式：LevelDB 使用POSIX的open()系统调用打开文件，返回一个文件描述符（fd）。只要 fd 有效，即使文件被unlink()，进程仍能通过 fd 读取文件内容（这是 UNIX 的设计哲学）。
3. 深挖RandomAccessFile实现：在posix_env.cc中，PosixSequentialFile和PosixRandomAccessFile都持有一个int fd_。崩溃点表明，fd_被关闭了，但Table对象仍在尝试使用它。
4. 根因确认：LevelDB 的Cache（LRUCache）会缓存Table对象。当一个 SSTable 文件被删除，Table对象如果还在 Cache 中，它持有的RandomAccessFile的fd_可能已经失效（例如，被close()或被操作系统回收）。后续对该Table的Get()操作就会触发崩溃。

解决方案：这是 LevelDB 的一个已知设计约束。生产环境必须禁止对 LevelDB 数据目录进行任何形式的手动文件操作。应通过 LevelDB 提供的DestroyDB()或RepairDB()API 来管理数据。对于误删，唯一的补救措施是立即从最近的备份中恢复。