作為開發人員，我們每天都要開發大量的接口，其中包括了讀接口和寫接口，而對于寫接口來說，除了要保證他的性能、可用性以外，還需要有一個重要的問題，那就是考慮如何保證接口的冪等性

Innodb是MySQL的執行引擎，MySQL是一種關系型數據庫，而Redis是一種非關系型數據庫。這兩者之間比較大的區別是：關系型數據庫以表的形式進行存儲數據，而非關系型數據庫以Key-value的形式存儲數據。

在InnoDB中，索引是采用B+樹實現的，在Redis中，ZSET是采用跳表（不只是跳表）實現的，無論是B+樹，還是跳表，都是性能很好的數據結構，那么，為什么InnoDB為什么不用跳表，Redis為什么不用B+樹？

我們都知道，MySQL是基于磁盤存儲的，Redis是基于內存存儲的。

而之所以Innodb用B+樹，主要是因為B+樹是一種磁盤IO友好型的數據結構，而Redis使用跳表，是因為跳表則是一種內存友好型的數據結構。

B+樹次磁盤友好？

首先，B+樹的葉子節點形成有序鏈表，可以方便地進行范圍查詢操作。對于磁盤存儲來說，順序讀取的效率要高于隨機讀取，因為它可以充分利用磁盤預讀和緩存機制，減少磁盤 I/O 的次數。

其次，由于B+樹的節點大小是固定的，因此可以很好地利用磁盤預讀特性，一次性讀取多個節點到內存中，這樣可以減少IO操作次數，提高查詢效率。

還有就是，B+樹的葉子節點都存儲數據，而非數據和指針混合，所以葉子節點的大小是固定的，而且節點的大小一般都會設置為一頁的大小，這就使得節點分裂和合并時，IO操作很少，只需讀取和寫入一頁。

所以，B+樹在設計上考慮了磁盤存儲的特點和性能優化，我曾經分析過，當Innodb中存儲2000萬數據的時候，只需要3次磁盤就夠了。

而跳表就不一樣了，跳表的索引節點通過跳躍指針連接，形成多級索引結構。這導致了跳表的索引節點在磁盤上存儲時會出現數據分散的情況，即索引節點之間的物理距離可能較遠。對于磁盤存儲來說，隨機訪問分散的數據會增加磁頭的尋道時間，導致磁盤 I/O 的性能下降。

為啥Redis用跳表？

既然B+樹這么多優點，為啥Redis要用跳表實現ZSET呢（不只是跳表，詳見下面鏈接）？而不是B+樹呢？

主要是因為Redis是一種基于內存的數據結構。他其實不需要考慮磁盤IO的性能問題，所以，他完全可以選擇一個簡單的數據結構，并且性能也能接受的 ，那么跳表就很合適。

因為跳表相對于B+樹來說，更簡單。相比之下，B+樹作為一種復雜的索引結構，需要考慮節點分裂和合并等復雜操作，增加了實現和維護的復雜度。

而且，Redis的有序集合經常需要進行插入、刪除和更新操作。跳表在動態性能方面具有良好的表現，特別是在插入和刪除操作上。相比之下，B+樹的插入和刪除需要考慮平衡性，所以還是成本挺高的。

總結

以上，就是關于《InnoDB為什么不用跳表，Redis為什么不用B+樹？》這個問題的我的一些理解，其實這個問題想要回答好還挺難的。

首先要知道為啥Innodb使用紅黑樹，其次還要了解Redis中的Zset數據結構，還需要知道跳表的原理。