以一个查询的例子来理解什么是索引：
select * from emp where sal>2000;
我们来看这个查询做了什么事情
切换到sys用户，打开跟踪器：
conn sys/change_on_install as sysdba
set autotrace on;
然后执行：
select * from scott.emp where sal>2000;
会发现：此时采用了全表扫描的模式（ table access full），既它会将查询条件与数据表中的每一条数据进行比较，这样的话会十分的浪费性能。
比如，我们在一个有五万数据的表中查询数据，但是在该表的第1.5万条数据之后就不是我们所需要的数据，但是这样查询依然会将剩下的三万五千条数据对比一下，这样十分浪费性能。
我们如果想不查剩下的三万五千条的话，我们首先想到的应该就是排序，但是，排序的话，他是在where子句之后执行的，所以order by 并不影响where的全表扫描。
这个时候我们就需要用树来解决：
树：
树的浅理解：
一组数：1500、900、600、500、700、1600、2000、2400、2200
我们发现，若是按这种查询的话，将会省去一大部分数据，比如：我们查询2300，这样的话，我们直接将1500左边的舍弃，直接从右面开始查，这样的查询就属于索引
而一旦使用了索引，就需要在数据之外维持一个内存空间，这个空间要保留这种排序关系，而这些索引定义的列，其都是通过伪列rowid来进行定位的。
创建索引：
create index 索引名 on 表名(列名);
*索引名建议（表名_列名_ind）*
一旦加入了索引机制，那么就不在执行全表扫描，而是使用索引进行查询，但是这个索引只针对于你规定的这个表的这个字段起作用，既where子句后面如果用的别的字段进行的查询，将不会起作用。
索引可以提高数据的查询性能；
如果用以索引的列的某个值改变了，则索引树的结构也一定要改变。（如上图中2000变为了8200，这样的话这个这条数据就不能再原处放了）
但是如果数据量特别庞大的话，则索引每一次改变都会消耗大量的内存空间，如果变为索引的那个列被频繁修改的话，那么索引就会变成彻底的拖累。反而会拖累整个数据库的性能，所以索引的使用要慎重