散列表
散列表的插入、刪除、查找操作的時間複雜度可以做到常量級的 O(1)，非常高效。
平衡二叉查找樹（紅黑樹）
二叉查找樹在比較平衡的情況下（紅黑樹是一種平衡二叉樹），插入、刪除、查找操作時間複雜度是 O(logn)。
跳錶
跳錶，插入、刪除、查找操作時間複雜度是 O(logn)。
散列表 vs 二叉查找樹
相對散列表，二叉查找樹好像並沒有什麼優勢，那我們爲什麼還要用二叉查找樹呢？
第一，散列表中的數據是無序存儲的，如果要輸出有序的數據，需要先進行排序。而對於二叉查找樹來說，我們只需要中序遍歷，就可以在 O(n) 的時間複雜度內，輸出有序的數據序列。
第二，散列表擴容耗時很多，而且當遇到散列衝突時，性能不穩定，儘管二叉查找樹的性能不穩定，但是在工程中，我們最常用的平衡二叉查找樹的性能非常穩定，時間複雜度穩定在 O(logn)。
比如：紅黑樹的插入、刪除、查找各種操作性能都比較穩定。對於工程應用來說，要面對各種異常情況，爲了支撐這種工業級的應用，我們更傾向於這種性能穩定的平衡二叉查找樹
第三，籠統地來說，儘管散列表的查找等操作的時間複雜度是常量級的，但因爲哈希衝突的存在，這個常量不一定比 logn 小，所以實際的查找速度可能不一定比 O(logn) 快。加上哈希函數的耗時，也不一定就比平衡二叉查找樹的效率高。
第四，散列表的構造比二叉查找樹要複雜，需要考慮的東西很多。比如散列函數的設計、衝突解決辦法、擴容、縮容等。平衡二叉查找樹只需要考慮平衡性這一個問題，而且這個問題的解決方案比較成熟、固定。
紅黑樹 vs 跳錶
紅黑樹是一種性能非常穩定的二叉查找樹，所以，在工程中，但凡是用到動態插入、刪除、查找數據的場景，都可以用到它。
不過，它實現起來比較複雜，如果自己寫代碼實現，難度會有些高，這個時候，我們其實更傾向用跳錶來替代它。
參考：
https://time.geekbang.org/column/intro/126