索引是对数据库表中一个或多个列（例如，employee 表的姓名 (name) 列）的值进行排序的结构。如果想按特定职员的姓来查找他或她，则与在表中搜索所有的行相比，索引有助于更快地获取信息。
例如这样一个查询：select * from table1 where id=10000。如果没有索引，必须遍历整个表，直到ID等于10000的这一行被找到为止；有了
索引之后(必须是在ID这一列上建立的索引)，即可在索引中查找。由于索引是经过某种算法优化过的，因而查找次数要少的多。可见，索引是用来定位的。
数据库
索引好比是一本书前面的目录，能
SQL Server的B树结构
加快数据库的查询速度。索引分为
聚簇索引和
非聚簇索引两种，聚簇索引 是按照数据存放的物理位置为顺序的，而非聚簇索引就不一样了；聚簇索引能提高多行检索的速度，而非聚簇索引对于单行的检索很快。
提示：尽管唯一索引有助于定位信息，但为获得最佳性能结果，建议改用
主键或
唯一约束。
唯一索引 唯一索引是不允许其中任何两行具有相同索引值的索引。
当现有数据中存在重复的键值时，大多数数据库不允许将新创建的唯一索引与表一起保存。数据库还可能防止添加将在表中创建重复键值的新数据。例如，如果在employee表中职员的姓(lname)上创建了唯一索引，则任何两个员工都不能同姓。
主键索引
数据库表经常有一列或多列组合，其值唯一标识表中的每一行。该列称为表的
主键。
在数据库关系图中为表定义主键将自动创建主键
索引，主键索引是
唯一索引的特定类型。该索引要求主键中的每个值都唯一。当在查询中使用主键索引时，它还允许对数据的快速访问。
在聚集索引中，表中行的物理顺序与键值的逻辑（索引）顺序相同。一个表只能包含一个聚集索引。
如果某索引不是聚集索引，则表中行的物理顺序与键值的逻辑顺序不匹配。与非聚集索引相比，聚集索引通常提供更快的数据访问速度。
索引列
可以基于数据库表中的单列或多列创建
索引。多列索引可以区分其中一列可能有相同值的行。
如果经常同时搜索两列或多列或按两列或多列排序时，索引也很有帮助。例如，如果经常在同一查询中为姓和名两列设置判据，那么在这两列上创建多列索引将很有意义。
确定索引的有效性：
检查查询的WHERE和JOIN子句。在任一子句中包括的每一列都是索引可以选择的对象。
对新索引进行试验以检查它对运行查询性能的影响。
考虑已在表上创建的索引数量。最好避免在单个表上有很多索引。
检查已在表上创建的索引的定义。最好避免包含共享列的重叠
索引。
检查某列中唯一数据值的数量，并将该数量与表中的行数进行比较。比较的结果就是该列的可选择性，这有助于确定该列是否适合建立索引，如果适合，确定索引的类型。
建立
索引的目的是加快对表中记录的查找或排序。为表设置索引要付出代价的：一是增加了数据库的存储空间，二是在插入和修改数据时要花费较多的时间(因为索引也要随之变动)。数据库索引就是为了提高表的搜索效率而对某些字段中的值建立的目录 。
创建索引可以大大提高系统的性能。第一，通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。第二，可以大大加快数据的检索速度，这也是创建索引的最主要的原因。第三，可以加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义。第四，在使用分组和排序子句进行数据检索时，同样可以显著减少查询中分组和排序的时间。第五，通过使用
索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。
因为，增加索引也有许多不利的方面。第一，创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加。第二，索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立
聚簇索引，那么需要的空间就会更大。第三，当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，这样就降低了数据的维护速度。
索引是建立在数据库表中的某些列的上面。在创建索引的时候，应该考虑在哪些列上可以创建索引，在哪些列上不能创建索引。一般来说，应该在这些列上创建索引：
在经常需要搜索的列上，可以加快搜索的速度；
在作为
主键的列上，强制该列的唯一性和组织表中数据的排列结构；
在经常用在连接的列上，这些列主要是一些
外键，可以加快连接的速度；在经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，其指定的范围是连续的；
在经常需要排序的列上创建索引，因为索引已经排序，这样查询可以利用索引的排序，加快排序查询时间；
在经常使用在WHERE子句中的列上面创建
索引，加快条件的判断速度。
同样，对于有些列不应该创建索引。一般来说，不应该创建索引的这些列具有下列特点：
第一，对于那些在查询中很少使用或者参考的列不应该创建索引。这是因为，既然这些列很少使用到，因此有索引或者无索引，并不能提高查询速度。相反，由于增加了索引，反而降低了系统的维护速度和增大了空间需求。
第二，对于那些只有很少数据值的列也不应该增加索引。这是因为，由于这些列的取值很少，例如人事表的性别列，在查询的结果中，
结果集的数据行占了表中数据行的很大比例，即需要在表中搜索的数据行的比例很大。增加
索引，并不能明显加快检索速度。
第三，对于那些定义为text, image和
bit数据类型的列不应该增加索引。这是因为，这些列的数据量要么相当大，要么取值很少,不利于使用索引。
第四，当修改性能远远大于检索性能时，不应该创建索引。这是因为，修改性能和检索性能是互相矛盾的。当增加索引时，会提高检索性能，但是会降低修改性能。当减少索引时，会提高修改性能，降低检索性能。因此，当修改操作远远多于检索操作时，不应该创建索引。
最普通的情况，是为出现在where子句的
字段建一个
索引。为方便讲述，先建立一个如下的表。
CREATE TABLE mytable(
idserial primary key,
category_id int not null default0,
user_id int not null default0,
adddate int not null default0
);
如果在查询时常用类似以下的语句：
SELECT * FROM mytable WHERE category_id=1;
最直接的应对之道，是为category_id建立一个简单的
索引：
CREATE INDEX mytable_categoryid ON mytable (category_id);
OK.如果有不止一个选择条件呢？例如：
SELECT * FROM mytable WHERE category_id=1 AND user_id=2;
第一反应可能是，再给user_id建立一个索引。不好，这不是一个最佳的方法。可以建立多重的
索引。
CREATE INDEX mytable_categoryid_userid ON mytable(category_id,user_id);
注意到在命名时的习惯了吗？使用"表名_
字段1名_字段2名"的方式。很快就会知道为什么这样做了。
现在已经为适当的字段建立了索引，不过，还是有点不放心吧，可能会问，数据库会真正用到这些索引吗？测试一下就OK，对于大多数的数据库来说，这是很容易的，只要使用EXPLAIN命令：
EXPLAIN
SELECT * FROM mytable
WHERE category_id=1 AND user_id=2;
This is what Postgres 7.1 returns (exactlyasI expected)
NOTICE:QUERY PLAN:
Index Scan using mytable_categoryid_userid on
mytable(cost=0.00..2.02 rows=1 width=16)
EXPLAIN
以上是postgres的数据，可以看到该数据库在查询的时候使用了一个
索引（一个好开始），而且它使用的是创建的第二个索引。看到上面命名的好处了吧，马上知道它使用适当的索引了。
接着，来个稍微复杂一点的，如果有个ORDERBY 子句呢？不管你信不信，大多数的数据库在使用orderby的时候，都将会从索引中受益。
SELECT * FROM mytable
WHERE category_id=1 AND user_id=2
ORDER BY adddate DESC;
很简单，就像为where子句中的
字段建立一个
索引一样，也为ORDER BY的子句中的字段建立一个索引：
CREATE INDEX mytable_categoryid_userid_adddate ON mytable (category_id,user_id,adddate);
注意:"mytable_categoryid_userid_adddate"将会被截短为"mytable_categoryid_userid_addda"
CREATE
EXPLAIN SELECT * FROM mytable
WHERE category_id=1 AND user_id=2
ORDER BY adddate DESC;
NOTICE:QUERY PLAN:
Sort(cost=2.03..2.03 rows=1 width=16)
->Index Scanusing mytable_categoryid_userid_addda
on mytable(cost=0.00..2.02 rows=1 width=16)
EXPLAIN
看看EXPLAIN的输出，数据库多做了一个没有要求的排序，这下知道性能如何受损了吧，看来对于数据库的自身运作是有点过于乐观了，那么，给数据库多一点提示吧。
为了跳过排序这一步，并不需要其它另外的
索引，只要将查询语句稍微改一下。这里用的是postgres，将给该数据库一个额外的提示--在ORDER BY语句中，加入where语句中的
字段。这只是一个技术上的处理，并不是必须的，因为实际上在另外两个字段上，并不会有任何的排序操作，不过如果加入，postgres将会知道哪些是它应该做的。
EXPLAIN SELECT * FROM mytable
WHERE category_id=1 AND user_id=2
ORDER BY category_id DESC,user_id DESC,adddate DESC;
NOTICE:QUERY PLAN:
Index Scan Backward using
mytable_categoryid_userid_addda on mytable(cost=0.00..2.02 rows=1 width=16)
EXPLAIN
现在使用料想的
索引了，而且它还挺聪明，知道可以从索引后面开始读，从而避免了任何的排序。
以上说得细了一点，不过如果数据库非常巨大，并且每日的页面请求达上百万算，想会获益良多的。不过，如果要做更为复杂的查询呢，例如将多张表结合起来查询，特别是where限制字句中的
字段是来自不止一个表格时，应该怎样处理呢？通常都尽量避免这种做法，因为这样数据库要将各个表中的东西都结合起来，然后再排除那些不合适的行，搞不好开销会很大。
如果不能避免，应该查看每张要结合起来的表，并且使用以上的策略来建立索引，然后再用EXPLAIN命令验证一下是否使用了料想中的索引。如果是的话，就OK。不是的话，可能要建立临时的表来将他们结合在一起，并且使用适当的索引。
要注意的是，建立太多的
索引将会影响更新和插入的速度，因为它需要同样更新每个
索引文件。对于一个经常需要更新和插入的表格，就没有必要为一个很少使用的where字句单独建立索引了，对于比较小的表，排序的开销不会很大，也没有必要建立另外的索引。
以上介绍的只是一些十分基本的东西，其实里面的学问也不少，单凭EXPLAIN是不能判定该方法是否就是最优化的，每个数据库都有自己的一些优化器，虽然可能还不太完善，但是它们都会在查询时对比过哪种方式较快，在某些情况下，建立
索引的话也未必会快，例如索引放在一个不连续的存储空间时，这会增加读磁盘的负担，因此，哪个是最优，应该通过实际的使用环境来检验。
在刚开始的时候，如果表不大，没有必要作索引，意见是在需要的时候才作索引，也可用一些命令来优化表，例如MySQL可用"OPTIMIZETABLE"。
一、 ROWID的概念
存储了row在数据文件中的具体位置：64位 编码的数据，A-Z, a-z, 0-9, +, 和 /，
row在数据块中的存储方式
SELECT ROWID, last_name FROM hr.employees WHERE department_id = 20;
比 如：OOOOOOFFFBBBBBBRRR
OOOOOO：data object number, 对应dba_objects.data_object_id
FFF：file#, 对应v$datafile.file#
BBBBBB：block#
RRR：row#
Dbms_rowid包
SELECT dbms_rowid.rowid_block_number('AAAGFqAABAAAIWEAAA') from dual;
具 体到特定的物理文件
二、 索引的概念
1、 类似书的目录结构
2、 Oracle 的“索引”对象，与表关联的可选对象，提高SQL查询语句的速度
3、 索引直接指向包含所查询值的行的位置，减少磁盘I/O
4、 与所索引的表是相互独立的物理结构
5、 Oracle 自动使用并维护索引，插入、删除、更新表后，自动更新索引
6、 语法：CREATE INDEX index ON table (column[, column]...);
7、 B-tree结构(非bitmap)：
[一]了解索引的工作原理：
表：emp
目标：查询Frank的工资salary
建立索 引：create index emp_name_idx on emp(name);
[试验]测试索引的作用：
1. 运行/rdbms/admin/utlxplan 脚本
2. 建立测试表
create table t as select * from dba_objects;
insert into t select * from t;
create table indextable
as select rownum id,owner,object_name,subobject_name,
object_id,data_object_id,object_type,created
from t;
3. set autotrace trace explain
4. set timing on
5. 分析表，可以得到cost
6. 查询 object_name=’DBA_INDEXES’
7. 在object_name列上建立索引
8. 再查询
[思考]索引的代价：
插入，更新
三、 唯一索引
1、 何时创建：当某列任意两行的值都不相同
2、 当建立Primary Key(主键)或者Unique constraint(唯一约束)时，唯一索引将被自动建立
3、 语法：CREATE UNIQUE INDEX index ON table (column);
4、 演示
四、 组合索引
1、 何时创建：当两个或多个列经常一起出现在where条件中时，则在这些列上同时创建组合索引
2、 组合索引中列的顺序是任意的，也无需相邻。但是建议将最频繁访问的列放在列表的最前面
3、 演示(组合列，单独列)
五、 位图索引
1、 何时创建：
列中有非常多的重复的值时候。例如某列保存了 “性别”信息。
Where 条件中包含了很多OR操作符。
较少的update操作，因为要相应的跟新所有的bitmap
2、 结构：位图索引使用位图作为键值，对于表中的每一数据行位图包含了TRUE(1)、FALSE(0)、或NULL值。
3、 优点：位图以一种压缩格式存放，因此占用的磁盘空间比标准索引要小得多
4、 语法：CREATE BITMAP INDEX index ON table (column[, column]...);
5、 掩饰：
create table bitmaptable as select * from indextable where owner in('SYS','PUBLIC');
分析，查找，建立索引，查找
六、 基于函数的索引
1、 何时创建：在WHERE条件语句中包含函数或者表达式时
2、 函数包括：算数表达式、PL/SQL函数、程序包函数、SQL函数、用户自定义函数。
3、 语法：CREATE INDEX index ON table (FUNCTION(column));
4、 演示
必须要分析表，并且 query_rewrite_enabled=TRUE
或者使用提示/*+ INDEX(ic_index)*/
七、 反向键索引
目的：比如索引值是一个自动增长的列：
多个用户对集中在少数块上的索引行进行修改，容易引起资源的争用，比如对数据块的等待。此时建立反向索 引。
性能问题：
语法：
重建为标准索引：反之不行
八、 键压缩索引
比如表landscp的数据如下：
site feature job
Britten Park, Rose Bed 1, Prune
Britten Park, Rose Bed 1, Mulch
Britten Park, Rose Bed 1,Spray
Britten Park, Shrub Bed 1, Mulch
Britten Park, Shrub Bed 1, Weed
Britten Park, Shrub Bed 1, Hoe
……
查询时，以上3列均在where条件中同时出现，所以建立基于以上3列的组合索引。但是发现重复值很多，所以考虑压缩特性。
Create index zip_idx
on landscp(site, feature, job)
compress 2;
将索引项分成前缀(prefix)和后缀(postfix)两部分。前两项被放置到前缀部分。
Prefix 0: Britten Park, Rose Bed 1
Prefix 1: Britten Park, Shrub Bed 1
实际所以的结构为：
0 Prune
0 Mulch
0 Spray
1 Mulch
1 Weed
1 Hoe
特点：组合索引的前缀部分具 有非选择性时，考虑使用压缩。减少I/O,增加性能。
九、 索引组织表(IOT)
将表中的数据按照索 引的结构存储在索引中，提高查询速度。
牺牲插入更新的性能，换取查询 性能。通常用于数据仓库，提供大量的查询，极少的插入修改工作。
必须指定主键。插入数据时，会根据主键列进行B树索引排序，写入磁盘。
十、 分区索引
簇:
A cluster is a group of tables that share the same data blocks because they share common columns and are often used together.
