PostgreSQL索引思考

当在看Monetdb列存行只支持IMPRINTS和ORDERED这两种索引，且只支持定长数值类型时，就在思考，对于列存，还有必要建索引吗？在PostgreSQL的索引就要灵活很多，我对常用列建合理的索引，是不是能达到列存的效果？（肯定没有）。

当然，有索引还是快很多：

1）对于整型列来说，应该是用ORDERED索引，建类似于btree索引，将数据按大小进行了排序，当执行> = < <= >= between in is等操作时，就非常快了，不需要整个列进行扫描比较。

2）对于字符串呢？ 列存对字符串的压缩还是比较给力的，对于特殊的字符串列，还可以用字典的方式来压缩。但是没有索引的话，就只能是进行全列扫描了，效率不可能太高。

一、PostgreSQL数据库的索引类型

1.Btree索引：
　　B-Tree索引主要用于等于和范围查询，特别是当索引列包含操作符" <、<=、=、>=和>"作为查询条件时，PostgreSQL的查询规划器都会考虑使用B-Tree索引。在使用BETWEEN、IN、IS NULL和IS NOT NULL的查询。　　　　      　　PostgreSQL也可以使用B-Tree索引。然而对于基于模式匹配操作符的查询，如LIKE、ILIKE、~和 ~*，仅当模式存在一个常量，且该常量位于模式字符串的开头时，如col LIKE 'foo%'或col ~ '^foo'，索引才会生效，否则将会执行全表扫描，如：col LIKE '%bar'。

　　适用于整型、时间类型数据列。

2.Hash索引：
　　散列(Hash)索引只能处理简单的等于比较。当索引列使用等于操作符进行比较时，查询规划器会考虑使用散列索引。
　　这里需要额外说明的是，PostgreSQL散列索引的性能不比B-Tree索引强，但是散列索引的尺寸和构造时间则更差。另外，由于散列索引操作目前没有记录WAL日志，因此一旦发生了数据库崩溃，我们将不得不用REINDEX重建散列索引。
　　
　　适用于字符串数据类型，而字符串一般的操作也是等于判断。

3.GIN索引：
　　GIN是倒排索引，存储被索引字段的VALUE或VALUE的元素，以及行号的list或tree。主要用于：当需要搜索多值类型内的VALUE时，适合多值类型，例如数组、全文检索、TOKEN。（根据不同的类型，支持相交、包含、大于、在左边、在右边等搜索）；

4.GIST索引：

　　GiST是一个通用的索引接口，可以使用GiST实现b-tree, r-tree等索引结构。一般在地图插件PostGIS中使用，且不同的类型，支持的索引检索也各不一样。例如：
　　1) 几何类型，支持位置搜索（包含、相交、在上下左右等），按距离排序。
　　2) 范围类型，支持位置搜索（包含、相交、在左右等）。
　　3) IP类型，支持位置搜索（包含、相交、在左右等）。
　　4) 空间类型（PostGIS），支持位置搜索（包含、相交、在上下左右等），按距离排序。
　　5) 标量类型，支持按距离排序。

还有一些其他比较特殊的索引类型，用的太少了。

二、复合索引，也就是多列索引

　　一般是针对用户对某个表的查询条件比较固定。这样可以考虑创建多列索引，多列索引中的单个列在被查询时，也可能会走多列索引。但是仅在查询包含多列索引的最左列时，效率最高，最可能走这个多列索引。

1.多列索引检索顺序：

当b+树的数据项是复合的数据结构，比如(name,age,sex)的时候，b+数是按照从左到右的顺序来建立搜索树的，比如当(张三,20,F)这样的数据来检索的时候，b+树会优先比较name来确定下一步的所搜方向，如果name相同再依次比较age和sex，最后得到检索的数据；但当(20,F)这样的没有name的数据来的时候，b+树就不知道下一步该查哪个节点，因为建立搜索树的时候name就是第一个比较因子，必须要先根据name来搜索才能知道下一步去哪里查询。比如当(张三,F)这样的数据来检索时，b+树可以用name来指定搜索方向，但下一个字段age的缺失，所以只能把名字等于张三的数据都找到，然后再匹配性别是F的数据了， 这个是非常重要的性质，即索引的最左匹配特性。

2.多列索引创建原则：

1) 最左前缀匹配原则，非常重要的原则，数据库会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配，比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)顺序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引则都可以用到，a,b,d的顺序可以任意调整；以index(a, b, c,d)为例，多列索引的利用情况是：
where a=3                                  是
where a=3 and b=5                          是
where a=3 and b=5 and c=4                  是
where b=3                                  否
where c=4                                  否
where a=3 and c=4                          a列能用到索引,b不能
where a=3 and b>10 and c=7                 a能,b能,c不能
where a=3 and b like 'xxx%' and c=7        a能,b能,c不能

2) =和in可以乱序，比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意顺序，mysql的查询优化器会帮你优化成索引可以识别的形式；
3) 尽量选择区分度高的列作为索引,区分度的公式是count(distinct col)/count(*)，表示字段不重复的比例，比例越大我们扫描的记录数越少，唯一键的区分度是1，而一些状态、性别字段可能在大数据面前区分度就是0，那可能有人会问，这个比例有什么经验值吗？使用场景不同，这个值也很难确定，一般需要join的字段我们都要求是0.1以上，即平均1条扫描10条记录；
4) 索引列不能参与计算，保持列“干净”，比如from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，原因很简单，b+树中存的都是数据表中的字段值，但进行检索时，需要把所有元素都应用函数才能比较，显然成本太大。所以语句应该写成create_time = unix_timestamp(’2014-05-29’);
5) 尽量的扩展索引，不要新建索引。比如表中已经有a的索引，现在要加(a,b)的索引，那么只需要修改原来的索引即可；

三、条件索引

四、部分索引

五、聚集索引

CLUSTER指示Postgres近似地基于索引indexname的度量对表进行存储建簇．索引必须已经在表上定义了。　
当对一个表建簇后，该表的物理存储将基于索引信息进行。建簇是静态的，也就是说，当表被更新后，改变的内容不会建簇。不会试图对更新过的记录重新建簇。如果需要，可以通过手工执行该命令的方法重建簇。 

注意：
该表实际上按索引顺序拷贝到了一个临时表中，然后重新改成原名。因此，在建簇时所有赋予的权限和其它索引都将丢失。　
如果你只是随机的访问表中的行，那么在堆表中的数据的实际存储顺序是无关紧要的。但是，如果你对某些数据的访问多于其他数据，而且有一个索引将这些数据分组，建蔟会提高查询速度。　 

另一个很有帮助的例子是当你用索引从一个表中取出几个记录时。如果你从一个表中请求一定索引范围的值，或者是一个索引过的值对应多行，建蔟也会有助于应用，因为如果索引标识出第一匹配行所在的堆存储页，所有其他行也可能已经在同一堆存储页里了，这样便节省了磁盘访问的时间，加速了查询。　 

有两种建簇方法：
第一种是用CLUSTER命令，此命令将原表按你声明的索引重新排列。这个动作在操作大表时可能会很慢，因为每一行都从堆存储页里按索引顺序取出，如果存储页表没有排序，整个表是随机存放在各个页面的，因而每行都要进行依次磁盘页面操作。虽然PostgreSQL有一个共享存储，但一个大表的主体是不可能都放到缓冲区的，需要经过多次交换。
另一个对数据建簇的方法是用SQL语句：　
SELECT　columnlist　INTO　TABLE　newtable FROM　table　ORDER　BY　columnlist
这个用法使用排序的代码ORDER BY来匹配索引，在对未排序的数据操作时速度快得多。然后你可以删除旧表，用ALTER TABLE/RENAME将newtable改成旧表名，并且重建所有索引。唯一的问题是OID不保留。这时再做聚集将快得多，因为大多数堆栈数据已经排过序了而且使用现有的索引，当然也可以不做聚集了。

部分参考：

http://www.cnblogs.com/stephen-liu74/archive/2012/05/09/2298182.html