不妨先看一下很普通的题目：
假设有几千几万个文件需要存放，该如何进行存储？
这个问题需要考虑几个问题：
1、给出1个文件名，我们如何快速找到文件？
2、这么多的文件，如果存放到1个文件夹，查找的效率肯定非常低，我们如何分文件夹存放？
3、分文件夹之后，我们如何确定文件存放在哪个文件夹里？
1、快速检索
快速查找文件，我们最容易想到“折半查找”，算法要求文件名有序，“文件按顺序存放”是非常重要的。
于是，这个问题就变成了：如何将有序的文件，存放到很多文件夹里？
2、Hash分区存放
我们可以参考《新华字典》的做法，取文件名的前两个字，只要是这两个字开头的文件，就存放同一个文件夹。
两个字可以产生成千上万种情况，似乎没那么明智，这时候我们就需要思考一些Hash算法。
例如：一切数据都可以转换为0和1，因此文件名也是一个数字，文件名与16 “按位与” 运算，就会产生0-15中的一个数字，按照这个规则，就可以将文件存储到16个分区。
（分区的问题：扩展分区的成本非常高，文件已经分成16个分区，发现16个分区不够用，要扩展到32个，这时候工作量非常大）
3、平衡树
数据都可以转换为0和1，那么就可以比较大小，因此，还可以有这样一个方案：
0-m的文件，存放在一个文件夹，m-n的文件，存放在另一个文件夹，最后n-MAX的文件，再用一个文件夹。
如果有一天，0-m文件夹存放的文件非常多了，我们还可以进行拆分，分成0-x文件夹，和x-m文件夹。
这个方案，每次查找文件的复杂度，都是一样的，而且，不论有多少文件，都可以进行扩展。
总结
上述的案例，已经解释了b-tree的大致原理，Oracle中的使用的是平衡树，案例中用的是文件夹，
“快速定位到某1个数据”，“数据按照顺序存储”，根据这两个特点，可以解释Oracle中的很多现象：
- in, >, <, =, between为什么能用到索引？索引能快速定位到等值的数据，因为数据是有序的，在它之后就比它大，之前的就比它小，其中 > 和 < 与数据量相关，数据过少时不走索引，因为数据量少直接查全表比索引快；
- 半模糊查询（like 'xxx%'）能用到索引，这是因为数据的前面一半存在，这样是可以排序的，以人名为例，知道你姓钱，按照百家姓排序，你就排在前面；
- not in, <>, != 如果只是判断记录是否存在，走索引可以说得通，但是从查询的角度上看，“不等查询” 几乎查询了表中的全部内容，全表检索效率更高；
- is null, is not null 在设置字段非空的时候，肯定不走索引；
- is null 因为b-tree不存储为空的值，所以不走索引；
- is not null 具体走不走索引，还是得看执行计划，原理上看可以走索引，但是is not null等于查询索引中的全部数据，不确定oracle程序员是否有其它考虑，因此需要更多的案例，目前没办法盖棺定论；
- 隐式转换：比如id是字符串，where id = 1，此时1是数字，需要将id转换成数字之后，才能比较，这样不走索引；
- 调用函数的情况：where to_number(id) = 1， 很明显，这种情况下，索引压根没存储to_number(id)之后的值，没办法进行检索。