idx

btree & hash索引：

http://www.kankanews.com/ICkengine/archives/127746.shtml

http://blog.csdn.net/tonyxf121/article/details/7976824

http://www.uml.org.cn/sjjm/201107145.asp

http://www.cnblogs.com/daduxiong/archive/2010/08/18/1802145.html

hash索引只能适合“=”（直等—）的查询。

btree索引适合的很多，“>,<,=,like......”等等。

order by ：

会使用索引（如果有索引）

对于limit...offset.....：

示例demo： http://blog.163.com/digoal@126/blog/static/163877040201411152640383/

demo中两个SQL语句只是offset的值发生了变更，就导致查询的速度相差甚广。这是因为

此SQL语句中在对create_time进行使用btree索引扫描（因为有索引）的时候扫描的row太多。

扫描row太多的原因：

1：where 部分数据太多。

2： where 部分 数据 create_time字段的值在中太过分散。

3：如上文作者所说，执行计划基本一样(除了limit部分的cost部分)但是 走索引扫描的记录却千差万别

如果想查看一个SQL语句扫描了多少row( explain verbose  analyze )，参见：

digoal=# explain verbose select * from aa order by a limit 10 offset 90;     
                                     QUERY PLAN                                      
-------------------------------------------------------------------------------------
 Limit  (cost=3.64..4.01 rows=10 width=22)
   Output: a, b
   ->  Index Scan using aa_pkey on public.aa  (cost=0.28..112.30 rows=3001 width=22)
         Output: a, b
(4 rows)

digoal=# explain verbose select * from aa where a<2000 order by a limit 10 offset 90; 
                                     QUERY PLAN                                     
------------------------------------------------------------------------------------
 Limit  (cost=4.15..4.58 rows=10 width=22)
   Output: a, b
   ->  Index Scan using aa_pkey on public.aa  (cost=0.28..44.13 rows=1020 width=22)
         Output: a, b
         Index Cond: (aa.a < 2000)
(5 rows)

digoal=# truncate table aa;
TRUNCATE TABLE
digoal=# create index idx_b on aa(b);
CREATE INDEX
digoal=# insert into aa select generate_series(1,1000),random();
INSERT 0 1000
digoal=# explain analyze select * from aa order by a limit 10 offset 90;
                                                        QUERY PLAN                                      
------------------------------------------------------------------------------------------------------
 Limit  (cost=3.64..4.01 rows=10 width=22) (actual time=0.083..0.089 rows=10 loops=1)
   ->  Index Scan using aa_pkey on aa  (cost=0.28..112.30 rows=3001 width=22) (actual time=0.034..0.076 rows=100 loops=1)
 Total runtime: 0.116 ms
(3 rows)

gist索引和gin索引

http://www.postgresql.org/docs/9.3/static/textsearch-indexes.html

http://www.postgresql.org/docs/9.3/static/pgstattuple.html  ( pgstattuple插件，查看tuple的统计状态)

http://blog.163.com/digoal@126/blog/static/163877040201192624726272/

区别：

1：在使用操作符“<->”的时候gin索引没有<-> oder by 操作，而gist有。

gin索引:

http://www.postgresql.org/docs/9.3/interactive/gin.html  Implementation

http://blog.163.com/digoal@126/blog/static/163877040201341625735128/

CREATE INDEX name ON table USING gin(column);

Creates a GIN (Generalized Inverted Index)-based index. The column must be of tsvector type.

一个表如果使用了gin索引的时候，那么在insert，update的时候如果数据量一多则会出现插入缓慢的迹象。是因为pg8.4之后使用了fastupdate技术对gin索引优化，提高速度的方法有两个：

1：work_mem参数的设置增大（默认1M)。

2： autovacuum 需要开启。

示例：

gist索引：

http://www.postgresql.org/docs/9.3/interactive/gist.html  Implementation

http://blog.163.com/digoal@126/blog/static/1638770402011918101412105/

CREATE INDEX name ON table USING gist(column);

Creates a GiST (Generalized Search Tree)-based index. The column can be of tsvector or tsquery type.