（1）为什么要使用树：
因为如果使用线性表进行操作，那么搜索的时间复杂度是O(n)规模的。而如果使用树这个数据集的话，能够把时间复杂度的规模降低到O(logn）规模。
（2）为什么使用二叉查找树：
构建二叉查找树，能够限制节点的左子树中的值都比当前节点的小，右子树的都比当前节点的大。这样子更有利于进行搜索，有利于进行二分查找。
（3）为什么使用平衡二叉树：
如果是非平衡二叉树，那么在构建树的过程中可能会出现一种情况，那就是树变成单支二叉树，也就是变成了链表的结构，此时搜索的时间复杂度又会变成O(n)规模。因此提出了使用平衡二叉树。控制左右子树的高度差不能超过1.此时就能够保证不会出现单支二叉树的情况。一般是构建AVL树。而且AVL树具有自平衡特性，因此保证其在失去平衡之后，可以自动调整回来，能够严格保证是一棵平衡二叉树。
（4）为什么使用红黑树：
AVL树确实挺好的。但是AVL树追求严格的平衡，因此在添加或者删除节点时，一定程度上会增加操作次数。而在红黑树中，只是追求相对平衡，因此在一定程序上能够提高效率。这就红黑树比较好的一点。适用于内存中。
（5）为什么使用B树：
B树的一个特点就是它是一种多分支树。这种树的中的每个节点可以存储多个内节点，通过这样子，可以大大降低树的高度。因此也可以大大提高树的搜索速度。因为对于树来说，其时间复杂度是与树的高度有关的。而且是成正比。正是因为它的这种特性，所以它的搜索效率挺高的。但是一般应用于外存中，好像是因为它的空间复杂度比较大，需要用到比较多的存储空间，所以比较适用于外存。
AVL树比红黑树更加平衡，但AVL树可能在插入和删除过程中引起更多旋转。因此，如果应用程序涉及许多频繁的插入和删除操作，则应首选Red Black树(如 Java 1.8中的HashMap)。如果插入和删除操作的频率较低，而搜索操作的频率较高，则AVL树应优先于红黑树。
关于二叉树的遍历：
只有平衡二叉树的前序遍历才是升序数据。普通二叉树谈前序中序后序没有意义。
平衡二叉查找树：简称平衡二叉树。由前苏联的数学家 Adelse-Velskil 和 Landis 在 1962 年提出的高度平衡的二叉树，根据科学家的英文名也称为 AVL 树。它具有如下几个性质：
1、可以是空树。
2、假如不是空树，任何一个结点的左子树与右子树都是平衡二叉树，并且高度之差的绝对值不超过 1。
对于查找问题，常用解法：一是基于各种平衡树，二是基于哈希表。还有一种特殊的是跳表。
跳表结构：
skiplist与平衡树、哈希表的比较
skiplist和各种平衡树（如AVL、红黑树等）的元素是有序排列的，而哈希表不是有序的。因此，在哈希表上只能做单个key的查找，不适宜做范围查找。所谓范围查找，指的是查找那些大小在指定的两个值之间的所有节点。
在做范围查找的时候，平衡树比skiplist操作要复杂。在平衡树上，我们找到指定范围的小值之后，还需要以中序遍历的顺序继续寻找其它不超过大值的节点。如果不对平衡树进行一定的改造，这里的中序遍历并不容易实现。而在skiplist上进行范围查找就非常简单，只需要在找到小值之后，对第1层链表进行若干步的遍历就可以实现。
平衡树的插入和删除操作可能引发子树的调整，逻辑复杂，而skiplist的插入和删除只需要修改相邻节点的指针，操作简单又快速。
从内存占用上来说，skiplist比平衡树更灵活一些。一般来说，平衡树每个节点包含2个指针（分别指向左右子树），而skiplist每个节点包含的指针数目平均为1/(1-p)，具体取决于参数p的大小。如果像Redis里的实现一样，取p=1/4，那么平均每个节点包含1.33个指针，比平衡树更有优势。
查找单个key，skiplist和平衡树的时间复杂度都为O(log n)，大体相当；而哈希表在保持较低的哈希值冲突概率的前提下，查找时间复杂度接近O(1)，性能更高一些。所以我们平常使用的各种Map或dictionary结构，大都是基于哈希表实现的。
从算法实现难度上来比较，skiplist比平衡树要简单得多。
在前面我们对于skiplist和平衡树、哈希表的比较中，其实已经不难看出Redis里使用skiplist而不用平衡树的原因了。现在我们看看，对于这个问题，Redis的作者 @antirez 是怎么说的：https://news.ycombinator.com/item?id=1171423
这里从内存占用、对范围查找的支持和实现难易程度这三方面总结的原因。
数据结构：
哈希表 （Hash Table）：哈希表的原理可以类比银行办业务取号，给每个人一个号（计算出的Hash值），叫某个号直接对应了某个人，索引效率是最高的O(1)，消耗的存储空间也相对更大。K-V存储组件以及各种编程语言提供的Map/Dict等数据结构，多数底层实现是用的哈希表。
二叉搜索树 （Binary Search Tree）：有序存储的二叉树结构，在编程语言中广泛使用的红黑树属于二叉搜索树，确切的说是“不完全平衡的”二叉搜索树。从C++、Java的TreeSet、TreeMap，到Linux的CPU调度，都能看到红黑树的影子。Java的HashMap在发现某个Hash槽的链表长度大于8时也会将链表升级为红黑树，而相比于红黑树“更加平衡”的AVL树反而实际用的更少。
平衡多路搜索树 （B-Tree）：这里的B指的是Balance而不是Binary，二叉树在大量数据场景会导致查找深度很深，解决办法就是变成多叉树，MongoDB的索引用的就是B-Tree。
叶节点相连的平衡多路搜索树 （B+ Tree）：B+ Tree是B-Tree的变体，只有叶子节点存数据，叶子与相邻叶子相连，MySQL的索引用的就是B+树，Linux的一些文件系统也使用的B+树索引inode。其实B+树还有一种在枝桠上再加链表的变体：B*树，暂时没想到实际应用。
日志结构合并树 （LSM Tree）：Log Structured Merge Tree，简单理解就是像日志一样顺序写下去，多层多块的结构，上层写满压缩合并到下层。LSM Tree其实本身是为了优化写性能牺牲读性能的数据结构，并不能算是索引，但在大数据存储和一些NoSQL数据库中用的很广泛，因此这里也列进去了。
字典树 （Trie Tree）：又叫前缀树，从树根串到树叶就是数据本身，因此树根到枝桠就是前缀，枝桠下面的所有数据都是匹配该前缀的。这种结构能非常方便的做前缀查找或词频统计，典型的应用有：自动补全、URL路由。其变体基数树（Radix Tree）在Nginx的Geo模块处理子网掩码前缀用了；Redis的Stream、Cluster等功能的实现也用到了基数树（Redis中叫Rax）。
跳表 （Skip List）：是一种多层结构的有序链表，插入一个值时有一定概率“晋升”到上层形成间接的索引。跳表更适合大量并发写的场景，不存在红黑树的再平衡问题，Redis强大的ZSet底层数据结构就是哈希加跳表。
倒排索引 （Inverted index）：这样翻译不太直观，可以叫“关键词索引”，比如书籍末页列出的术语表就是倒排索引，标识出了每个术语出现在哪些页，这样我们要查某个术语在哪用的，从术语表一查，翻到所在的页数即可。倒排索引在全文索引存储中经常用到，比如ElasticSearch非常核心的机制就是倒排索引；Prometheus的时序数据库按标签查询也是在用倒排索引。
主键：
数据库主键之争 ：自增长 vs UUID。主键是很多数据库非常重要的索引，尤其是MySQL这样的RDBMS会经常面临这个难题：是用自增长的ID还是随机的UUID做主键？
自增长ID的性能最高，但不好做分库分表后的全局唯一ID，自增长的规律可能泄露业务信息；而UUID不具有可读性且太占存储空间。
争执的结果就是找一个兼具二者的优点的折衷方案：
用雪花算法生成分布式环境全局唯一的ID作为业务表主键，性能尚可、不那么占存储、又能保证全局单调递增，但引入了额外的复杂性，再次体现了取舍之道。
再回到数据库中的索引，建索引要注意哪些点呢？
定义好主键并尽量使用主键，多数数据库中，主键是效率最高的聚簇索引；
在Where或Group By、Order By、Join On条件中用到的字段也要按需建索引或联合索引，MySQL中搭配explain命令可以查询DML是否利用了索引；
类似枚举值这样重复度太高的字段不适合建索引（如果有位图索引可以建），频繁更新的列不太适合建索引；
单列索引可以根据实际查询的字段升级为联合索引，通过部分冗余达到索引覆盖，以避免回表的开销；
尽量减少索引冗余，比如建A、B、C三个字段的联合索引，Where条件查询A、A and B、A and B and C
都可以利用该联合索引，就无需再给A单独建索引了；根据数据库特有的索引特性选择适合的方案，比如像MongoDB，还可以建自动删除数据的TTL索引、不索引空值的稀疏索引、地理位置信息的Geo索引等等。
数据库之外，在代码中也能应用索引的思维，比如对于集合中大量数据的查找，使用Set、Map、Tree这样的数据结构，其实也是在用哈希索引或树状索引，比直接遍历列表或数组查找的性能高很多。
