InnoDB为什么不用跳表，Redis为什么不用B&#x2B；树？

最新推荐文章于 2025-11-15 16:30:03 发布

转载最新推荐文章于 2025-11-15 16:30:03 发布 · 23 阅读

0 ·

CC 4.0 BY-SA版权

原文链接：https://www.cnblogs.com/heyonggang/p/19032169

文章标签：

#it

要回答为什么 InnoDB（MySQL 的存储引擎） 使用 B+ 树而不是跳表（Skip List），以及为什么 Redis 使用跳表而不是 B+ 树，需要分析两者的数据结构特性、使用场景和设计目标。以下是详细的对比和原因分析。

1. InnoDB 为什么使用 B+ 树而不是跳表？

B+ 树的特点

结构：B+ 树是一种多路平衡搜索树，非叶子节点存储键值，叶子节点存储完整数据（聚簇索引）或键值+指针（非聚簇索引），叶子节点通过双向链表连接。
优势：
- 高效范围查询：叶子节点链表支持快速顺序访问，适合 WHERE id BETWEEN 10 AND 20 等查询。
- 低树高：多路分支（每个节点存储多个键）减少树高，降低磁盘 I/O。
- 磁盘优化：节点大小与 InnoDB 页面（默认 16KB）对齐，最大化 I/O 效率。
- 并发支持：支持细粒度锁（如行锁、间隙锁）和 MVCC（多版本并发控制），适合事务性数据库。
劣势：
- 键值重复存储，增加空间开销。
- 插入/更新可能导致页面分裂，维护成本较高。

说明：

在B+树中，非叶子节点存储键值（索引字段），而叶子节点存储完整的键值和数据（或数据指针）。这意味着同一个键值可能会在非叶子节点和叶子节点中重复出现，导致存储空间的冗余
例如，在一个name字段的索引中，name值会在非叶子节点和叶子节点中都存储，增加了存储开销。

跳表的特点

结构：跳表是一种基于链表的概率性数据结构，通过多层索引（随机层数）加速查找，类似平衡树的二分搜索。
优势：
- 简单实现：相比 B+ 树，跳表实现更简单，代码复杂度低。
- 动态更新：插入和删除操作效率较高，平均时间复杂度为 O(log n)，无需复杂平衡操作。
- 内存友好：跳表基于指针，适合内存操作，空间利用率较高。
劣势：
- 概率性性能：跳表的性能依赖随机层分配，最坏情况退化为 O(n)。
- 范围查询较弱：虽然支持范围查询，但需要逐节点遍历链表，效率不如 B+ 树的顺序链表。
- 磁盘 I/O 不友好：跳表节点大小不固定，难以与磁盘页面对齐，增加 I/O 开销。

为什么 InnoDB 选择 B+ 树？

磁盘 I/O 优化：
- InnoDB 是磁盘数据库，查询性能受限于磁盘 I/O。B+ 树的节点设计与页面大小对齐（16KB），每次 I/O 可读取多个键值，减少 I/O 次数。
- 跳表的节点大小不固定，难以优化磁盘 I/O，可能导致更多随机读取，性能下降。
高效范围查询：
- 数据库常见操作包括范围查询（如 SELECT * FROM table WHERE id BETWEEN 10 AND 20）。B+ 树的叶子节点通过双向链表连接，支持高效顺序访问。
- 跳表需要逐节点遍历，范围查询效率较低，尤其在数据量大时。
并发和事务支持：
- InnoDB 支持复杂的事务隔离级别（如可重复读）和 MVCC。B+ 树的结构便于实现行锁、间隙锁和版本控制，减少锁冲突。
- 跳表的链表结构难以支持细粒度锁，MVCC 实现复杂，可能导致并发性能下降。
稳定性能：
- B+ 树是平衡树，查询时间复杂度稳定为 O(log n)。跳表的性能依赖随机层分配，最坏情况退化为 O(n)，不适合对性能一致性要求高的数据库。
数据量和持久化：
- InnoDB 处理大规模数据（百万到亿级记录），B+ 树的低树高和顺序存储适合磁盘环境。
- 跳表更适合内存数据库或较小数据集，难以应对大规模磁盘存储。

总结

InnoDB 选择 B+ 树是因为它在磁盘 I/O 优化、范围查询效率、并发支持和稳定性能方面更适合关系型数据库的需求。跳表的概率性性能、较弱的范围查询支持和磁盘不友好特性使其不适合 InnoDB 的场景。

2. Redis 为什么使用跳表而不是 B+ 树？

Redis 的特点

Redis 是一个内存数据库，数据存储在内存中，I/O 延迟极低，查询性能主要受 CPU 和内存访问速度限制。
Redis 的有序集合（Sorted Set，ZSET）使用跳表作为主要数据结构，支持快速插入、删除、查找和范围查询。

跳表在 Redis 中的优势

内存操作优化：
- 跳表基于链表和指针，节点大小灵活，适合内存环境。内存访问速度快，跳表无需像 B+ 树那样优化磁盘页面大小。
- B+ 树的节点设计（大节点、多键）针对磁盘 I/O，在内存中可能导致空间浪费和复杂维护。
简单实现：
- 跳表实现比 B+ 树简单，代码复杂度低，维护成本小。Redis 强调高性能和轻量级，跳表符合这一设计哲学。
- B+ 树需要复杂的平衡操作（如节点分裂、合并），增加开发和维护成本。
动态更新效率：
- Redis 的 ZSET 频繁涉及插入和删除操作（如 ZADD、ZREM）。跳表的插入/删除平均时间复杂度为 O(log n)，无需复杂平衡，适合高频更新。
- B+ 树的插入/更新可能导致节点分裂或合并，成本较高，尤其在内存中无明显 I/O 优势。
范围查询支持：
- ZSET 常用于范围查询（如 ZRANGEBYSCORE）。跳表通过底层链表支持范围查询，虽然效率不如 B+ 树的双向链表，但在内存中差异较小。
- Redis 数据量通常较小（内存限制），跳表足以满足范围查询需求。
空间效率：
- 跳表节点只存储必要指针和数据，空间利用率较高。B+ 树的键值重复存储（非叶子节点和叶子节点）在内存中可能浪费空间。
- Redis 追求内存高效，跳表更适合。

B+ 树的劣势在 Redis 中

内存不友好：
- B+ 树节点设计为大块（如 16KB），在内存中可能导致空间浪费，且节点分裂/合并操作复杂。
- 跳表的节点小且灵活，内存分配更高效。
复杂性：
- B+ 树需要维护多路平衡，代码复杂，不符合 Redis 轻量级设计。
- 跳表通过随机层分配实现近似平衡，简单且性能足够。
无磁盘 I/O 需求：
- Redis 是内存数据库，I/O 成本几乎为零，B+ 树的磁盘优化优势（如低树高、页面对齐）无用武之地。
- 跳表的 O(log n) 查找性能在内存中已足够快。
并发需求不同：
- Redis 是单线程模型，依赖事件驱动处理并发，无需复杂锁机制。跳表的简单结构适合单线程操作。
- B+ 树在 InnoDB 中支持复杂的事务和锁机制，但在 Redis 的单线程环境中显得过于复杂。

Redis 中跳表的使用

Redis 的 ZSET 使用跳表存储元素及其分数（score），支持快速查找（ZSCORE）、排名（ZRANK）和范围查询（ZRANGEBYSCORE）。
跳表结合哈希表（存储元素到分数的映射）实现 ZSET，提供高效的插入、删除和查询性能。

示例：

/* by 01022.hk - online tools website : 01022.hk/zh/json2get.html */
ZADD myzset 1 "user1" 2 "user2" 3 "user3"
ZRANGEBYSCORE myzset 1 2

跳表快速定位分数范围 [1, 2]，通过链表遍历返回结果。

总结

Redis 选择跳表是因为它在内存环境中简单高效，支持动态更新、范围查询和排名操作，符合 Redis 轻量级、高性能的设计目标。B+ 树的磁盘优化和复杂平衡机制在内存数据库中无明显优势，且维护成本高。

3. B+ 树与跳表的对比总结

特性	B+ 树	跳表
结构	多路平衡树，叶子节点链表连接	多层链表，概率性平衡
查询复杂度	O(log n)，稳定	O(log n) 平均，O(n) 最坏
范围查询	高效（双向链表）	较慢（逐节点遍历）
插入/删除	O(log n)，需节点分裂/合并	O(log n)，简单随机层分配
空间占用	键值重复，占用较多	灵活，空间效率较高
磁盘优化	节点与页面对齐，I/O 效率高	不适合磁盘，随机访问多
并发支持	支持细粒度锁、MVCC	简单结构，适合单线程
适用场景	磁盘数据库（InnoDB），大规模数据	内存数据库或较小数据集