postgres 唯一约束还用加索引么

唯一约束可以用于保证在基表中增加一条记录时，一个或多个列值是唯一的。如果已经给一个或以上列定义了唯一约束，那么任何 *** 作都不可能替换这些列中的复制的值。尽管唯一的、系统要求的索引是用来加强唯一约束，但是定义唯一约束和创建唯一索引...

问题源自一个帅哥在建索引发生表锁的问题。先介绍一下Postgresql的建索引语法：Version:9.1CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ name ] ON table [ USING method ]( { column | ( expression ) } [ COLLATE collation ] [ opclass ] [ ASC | DESC ] [ NULLS { FIRST | LAST } ] [, ...] )[ WITH ( storage_parameter = value [, ... ] ) ][ TABLESPACE tablespace ][ WHERE predicate ]这里不解释语法的诸多参数使用(排序，使用方法，填充因子等)，主要说一下concurrently的使用场景。正常情况下Postgresql建立普通btree索引时会阻塞DML(insert,update,delete) *** 作，直到索引完成，期间读 *** 作不受阻塞。当只有一个用户 *** 作这当然没问题，但是在生产环境，并发比较高的情况下，特别是大表建索引就不能这么 *** 作了，不然用户要跳起来骂娘了，点个按钮一天还没反应过来。--使用Postgresql提供了一个参数，可以在线建立索引的时候避免因写数据而锁表，这个参数叫concurrently。使用很简单，就是用create index concurrently来代替create index即可。--副作用当然了，使用这个参数是有副作用的，不使用这个参数建索引时DB只扫描一次表，使用这个参数时，会引发DB扫两次表，同时等待所有潜在会读到该索引的事务结束，这么一来，系统的CPU和IO，内存等会受一点影响，所以综合考虑，仍然让用户自行选择，而不是默认。--失败在使用concurrently参数建索引时，有可能会遇到失败的情况，比如建唯一索引索引发现数据有重复，又或者用户发现建索引时建错字段的，取消建索引 *** 作了。此时该表上会存在一个索引，这是因为带这个参数的建索引命令一经发出，就首先会在系统的日志表里先插一个索引记录进去，又因为这个索引最终建失败了，所以会被标记一个INVALID的状态，如下：postgres=# \d t_kenyonTable public.t_kenyonColumn | Type | Modifiers--------+---------+-----------col| integer |Indexes:idx btree (col) INVALID--重建遇到上述失效的索引重建时两个办法，一个是drop index index_name，然后再执行create index concurrently。还有一个是执行reindex index_name命令，但是后者不支持concurrent参数。--总结

---