引出

想象一下，你正在一家巨大的图书馆工作，这里藏书百万册，读者络绎不绝，每个人都想尽快找到他们想要的书籍。图书馆的布局有两种设计方案摆在你面前：

方案A：使用传统的目录卡片系统，就像老式的图书馆一样，每本书的信息都写在一张卡片上，按照字母顺序排列在一个巨大的抽屉柜里。这听起来就像是线性的数据存储，查找一本书的性能是O(n)——如果我们要找的是最后一本书，可能要翻阅整个抽屉！

方案B：使用现代的计算机系统，它采用B+树结构来索引所有的书籍。这意味着无论你要找哪一本书，计算机都能迅速定位，就像有了GPS导航一样，查找性能提升到了O(log N)。

那么，如果有人建议我们用跳表来代替B+树呢？跳表就像是在图书馆的每排书架上方都挂了一个指示牌，每个指示牌又指向下一个指示牌，这样找书时就可以跳跃式前进，减少行走的距离，性能同样是O(log N)，并且实现也很简单，那为什么Mysql的索引不使用跳表呢？用跳表做索引的Mysql又有什么不一样呢？

MySQL的B+树索引：

MySQL主要面向磁盘存储，其中的InnoDB存储引擎使用B+树作为索引结构。B+树具有以下特点：

1. 所有的叶子节点都存储实际的数据，非叶子节点只存储索引信息。
2. 高度相对较低，能够有效地减少磁盘I/O次数，这是因为磁盘的访问速度远慢于内存。
3. B+树的节点通常较大，可以容纳更多的键值对，这同样减少了磁盘I/O的次数。
4. 节点大小通常与页大小对齐，以优化磁盘读写。
   

Redis的跳表索引：

Redis是一个内存数据库，其设计目标是提供高速的数据存取能力。跳表（Skiplist）作为索引结构，有以下优势：

1. 实现简单，易于理解和维护。
2. 平均情况下，跳表提供了O(log N)的查找性能，这与平衡树相似。
3. 跳表在内存中运行，不需要考虑磁盘I/O的开销。
4. 跳表的随机性允许它在插入和删除操作时保持良好的性能，避免了如平衡树那样的频繁旋转操作。

MySQL如果使用跳表：

如果MySQL使用跳表，那么它的性能特征会有所不同。MySQL是为大规模数据存储和复杂事务设计的。它处理的数据量可能达到TB甚至PB级别，这些数据主要存储在磁盘上，由于跳表主要针对内存优化，MySQL可能无法充分利用跳表的优势，反而会因为频繁的磁盘I/O而降低性能。此外，跳表的多级索引需要额外的内存空间，这在磁盘存储环境中可能会导致更大的存储开销。

当然了，Mysql不同存储引擎索引也有用跳表来实现的，比如：RocksDB
他的写入性能确实要比InnoDB要好，但读性能确实要比InnoDB差了不少。

思考：为什么Redis使用跳表而不使用B+树或二叉树呢？

Redis选用跳表作为有序集合(ZSET)的底层数据结构，主要是考虑到其内存数据库的特性。跳表提供类似B+树的O(log N)时间复杂度，但实现更简单，维护成本低，尤其适合内存环境，无需顾虑磁盘I/O优化。尽管跳表在极端情况下的空间效率略逊，Redis的内存管理能消化这一劣势。跳表的随机性和动态层级调整机制使其在处理动态数据集时表现优异，无需复杂的平衡操作。加之Redis的单线程设计，跳表避免了并发控制的复杂性，确保了稳定高效的性能。总之，跳表的特性完美契合了Redis对高性能、易实现和低维护需求的追求，在内存中展现出了独特优势。

小结

简而言之，如果MySQL使用跳表做索引，理论上可以实现O(log N)的查询性能，但实际的磁盘I/O效率和并发控制能力可能会大打折扣。因此，MySQL选择了B+树，它就像一个专门为大型图书馆定制的超级导航系统，让海量数据的查找和维护变得既快速又稳定。

所以，下次当有人问起为什么MySQL不用跳表做索引时，你可以告诉他们：“那是因为MySQL的‘图书馆’太大太忙了，需要一个更专业的导航员——B+树！”