索引是对数据库表中一列或多列的值进行排序的一种结构，使用索引可快速访问数据库表中的特定信息。
技术原理
索引是对数据库表中一个或多个列（例如，employee 表的姓名 (name) 列）的值进行排序的结构。如果想按特定职员的姓来查找他或她，则与在表中搜索所有的行相比，索引有助于更快地获取信息。
例如这样一个查询：select * from table1 where id=10000。如果没有 索引，必须遍历整个表，直到ID等于10000的这一行被找到为止；有了索引之后(必须是在ID这一列上建立的索引)，即可在索引中查找。由于索引是经过某种算法优化过的，因而查找次数要少的多。可见， 索引是用来定位的。
主要种类
数据库 索引好比是一本书前面的目录，能加快数据库的查询速度。索引分为 聚簇索引和 非聚簇索引两种，聚簇索引 是按照数据存放的物理位置为顺序的，而非聚簇索引就不一样了；聚簇索引能提高多行检索的速度，而非聚簇索引对于单行的检索很快。
根据数据库的功能，可以在 数据库设计器中创建三种 索引： 唯一索引、主键索引和 聚集索引。有关数据库所支持的 索引功能的详细信息，请参见数据库文档。
基本特点
建立 索引的目的是加快对表中记录的 查找或 排序。为表设置 索引要付出代价的：一是增加了数据库的 存储空间，二是在插入和修改数据时要花费较多的时间(因为索引也要随之变动)。数据库索引就是为了提高表的搜索效率而对某些字段中的值建立的目录 。
创建 索引可以大大提高系统的性能。第一，通过创建唯一性 索引，可以保证数据库表中每一行数据的唯一性。第二，可以大大加快数据的检索速度，这也是创建 索引的最主要的原因。第三，可以加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义。第四，在使用分组和排序子句进行数据检索时，同样可以显著减少查询中分组和排序的时间。第五，通过使用 索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。
因为，增加 索引也有许多不利的方面。第一，创建 索引和维护 索引要耗费时间，这种时间随着数据量的增加而增加。第二， 索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立 聚簇索引，那么需要的空间就会更大。第三，当对表中的数据进行增加、删除和修改的时候， 索引也要动态的维护，这样就降低了数据的维护速度。
注意事项
索引是建立在数据库表中的某些列的上面。在创建 索引的时候，应该考虑在哪些列上可以创建索引，在哪些列上不能创建索引。一般来说，应该在这些列上创建 索引：
在经常需要搜索的列上，可以加快搜索的速度；
在作为 主键的列上，强制该列的唯一性和组织表中数据的排列结构；
在经常用在连接的列上，这些列主要是一些 外键，可以加快连接的速度；在经常需要根据范围进行搜索的列上创建 索引，因为索引已经排序，其指定的范围是连续的；
在经常需要排序的列上创建 索引，因为索引已经排序，这样查询可以利用索引的排序，加快排序查询时间；
在经常使用在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"。
