postgresql 建立索引

一、索引的类型：

创新互联-专业网站定制、快速模板网站建设、高性价比秦皇岛网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式秦皇岛网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖秦皇岛地区。费用合理售后完善，十余年实体公司更值得信赖。

PostgreSQL提供了多种索引类型：B-Tree、Hash、GiST和GIN，由于它们使用了不同的算法，因此每种索引类型都有其适合的查询类型，缺省时，CREATE INDEX命令将创建B-Tree索引。

1. B-Tree:

CREATE TABLE test1 (

id integer,

content varchar

);

CREATE INDEX test1_id_index ON test1 (id);

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：

CREATE INDEX name ON table USING hash (column);

散列(Hash)索引只能处理简单的等于比较。当索引列使用等于操作符进行比较时，查询规划器会考虑使用散列索引。

这里需要额外说明的是，PostgreSQL散列索引的性能不比B-Tree索引强，但是散列索引的尺寸和构造时间则更差。另外，由于散列索引操作目前没有记录WAL日志，因此一旦发生了数据库崩溃，我们将不得不用REINDEX重建散列索引。

3. GiST：

GiST索引不是一种单独的索引类型，而是一种架构，可以在该架构上实现很多不同的索引策略。从而可以使GiST索引根据不同的索引策略，而使用特定的操作符类型。

4. GIN：

GIN索引是反转索引，它可以处理包含多个键的值(比如数组)。与GiST类似，GIN同样支持用户定义的索引策略，从而可以使GIN索引根据不同的索引策略，而使用特定的操作符类型。作为示例，PostgreSQL的标准发布中包含了用于一维数组的GIN操作符类型，如：、=、等。

二、复合索引：

PostgreSQL中的索引可以定义在数据表的多个字段上，如：

CREATE TABLE test2 (

major int,

minor int,

name varchar

}

CREATE INDEX test2_mm_idx ON test2 (major, minor);

1. B-Tree类型的复合索引：

在B-Tree类型的复合索引中，该索引字段的任意子集均可用于查询条件，不过，只有当复合索引中的第一个索引字段(最左边)被包含其中时，才可以获得最高效率。

2. GiST类型的复合索引：

在GiST类型的复合索引中，只有当第一个索引字段被包含在查询条件中时，才能决定该查询会扫描多少索引数据，而其他索引字段上的条件只是会限制索引返回的条目。假如第一个索引字段上的大多数数据都有相同的键值，那么此时应用GiST索引就会比较低效。

3. GIN类型的复合索引：

与B-Tree和GiST索引不同的是，GIN复合索引不会受到查询条件中使用了哪些索引字段子集的影响，无论是哪种组合，都会得到相同的效率。

使用复合索引应该谨慎。在大多数情况下，单一字段上的索引就已经足够了，并且还节约时间和空间。除非表的使用模式非常固定，否则超过三个字段的索引几乎没什么用处。

三、组合多个索引：

PostgreSQL可以在查询时组合多个索引(包括同一索引的多次使用)，来处理单个索引扫描不能实现的场合。与此同时，系统还可以在多个索引扫描之间组成AND和OR的条件。比如，一个类似WHERE x = 42 OR x = 47 OR x = 53 OR x = 99的查询，可以被分解成四个独立的基于x字段索引的扫描，每个扫描使用一个查询子句，之后再将这些扫描结果OR在一起并生成最终的结果。另外一个例子是，如果我们在x和y上分别存在独立的索引，那么一个类似WHERE x = 5 AND y = 6的查询，就会分别基于这两个字段的索引进行扫描，之后再将各自扫描的结果进行AND操作并生成最终的结果行。

为了组合多个索引，系统扫描每个需要的索引，然后在内存里组织一个BITMAP，它将给出索引扫描出的数据在数据表中的物理位置。然后，再根据查询的需要，把这些位图进行AND或者OR的操作并得出最终的BITMAP。最后，检索数据表并返回数据行。表的数据行是按照物理顺序进行访问的，因为这是位图的布局，这就意味着任何原来的索引的排序都将消失。如果查询中有ORDER BY子句，那么还将会有一个额外的排序步骤。因为这个原因，以及每个额外的索引扫描都会增加额外的时间，这样规划器有时候就会选择使用简单的索引扫描，即使有多个索引可用也会如此。

四、唯一索引：

CREATE UNIQUE INDEX name ON table (column [, ...]);

五、表达式索引：

表达式索引主要用于在查询条件中存在基于某个字段的函数或表达式的结果与其他值进行比较的情况，如：

SELECT * FROM test1 WHERE lower(col1) = 'value';

此时，如果我们仅仅是在col1字段上建立索引，那么该查询在执行时一定不会使用该索引，而是直接进行全表扫描。如果该表的数据量较大，那么执行该查询也将会需要很长时间。解决该问题的办法非常简单，在test1表上建立基于col1字段的表达式索引，如：

CREATE INDEX test1_lower_col1_idx ON test1 (lower(col1));

SELECT * FROM people WHERE (first_name || ' ' || last_name) = 'John Smith';

和上面的例子一样，尽管我们可能会为first_name和last_name分别创建独立索引，或者是基于这两个字段的复合索引，在执行该查询语句时，这些索引均不会被使用，该查询能够使用的索引只有我们下面创建的表达式索引。

CREATE INDEX people_names ON people ((first_name || ' ' || last_name));

CREATE INDEX命令的语法通常要求在索引表达式周围书写圆括弧，就像我们在第二个例子里显示的那样。如果表达式只是一个函数调用，那么可以省略，就像我们在第一个例子里显示的那样。

从索引维护的角度来看，索引表达式要相对低效一些，因为在插入数据或者更新数据的时候，都必须为该行计算表达式的结果，并将该结果直接存储到索引里。然而在查询时，PostgreSQL就会把它们看做WHERE idxcol = 'constant'，因此搜索的速度等效于基于简单索引的查询。通常而言，我们只是应该在检索速度比插入和更新速度更重要的场景下使用表达式索引。

六、部分索引：

部分索引(partial index)是建立在一个表的子集上的索引，而该子集是由一个条件表达式定义的(叫做部分索引的谓词)。该索引只包含表中那些满足这个谓词的行。

由于不是在所有的情况下都需要更新索引，因此部分索引会提高数据插入和数据更新的效率。然而又因为部分索引比普通索引要小，因此可以更好的提高确实需要索引部分的查询效率。见以下三个示例：

1. 索引字段和谓词条件字段一致：

CREATE INDEX access_log_client_ip_ix ON access_log(client_ip)

WHERE NOT (client_ip inet '192.168.100.0' AND client_ip inet '192.168.100.255');

下面的查询将会用到该部分索引：

SELECT * FROM access_log WHERE url = '/index.html' AND client_ip = inet '212.78.10.32';

下面的查询将不会用该部分索引：

一个不能使用这个索引的查询可以是

SELECT * FROM access_log WHERE client_ip = inet '192.168.100.23';

2. 索引字段和谓词条件字段不一致：

PostgreSQL支持带任意谓词的部分索引，唯一的约束是谓词的字段也要来自于同样的数据表。注意，如果你希望你的查询语句能够用到部分索引，那么就要求该查询语句的条件部分必须和部分索引的谓词完全匹配。 准确说，只有在PostgreSQL能够识别出该查询的WHERE条件在数学上涵盖了该索引的谓词时，这个部分索引才能被用于该查询。

CREATE INDEX orders_unbilled_index ON orders(order_nr) WHERE billed is not true;

下面的查询一定会用到该部分索引：

SELECT * FROM orders WHERE billed is not true AND order_nr 10000;

那么对于如下查询呢？

SELECT * FROM orders WHERE billed is not true AND amount 5000.00;

这个查询将不像上面那个查询这么高效，毕竟查询的条件语句中没有用到索引字段，然而查询条件"billed is not true"却和部分索引的谓词完全匹配，因此PostgreSQL将扫描整个索引。这样只有在索引数据相对较少的情况下，该查询才能更有效一些。

下面的查询将不会用到部分索引。

SELECT * FROM orders WHERE order_nr = 3501;

3. 数据表子集的唯一性约束：

CREATE TABLE tests (

subject text,

target text,

success boolean,

...

);

CREATE UNIQUE INDEX tests_success_constraint ON tests(subject, target) WHERE success;

该部分索引将只会对success字段值为true的数据进行唯一性约束。在实际的应用中，如果成功的数据较少，而不成功的数据较多时，该实现方法将会非常高效。

七、检查索引的使用：

见以下四条建议：

1. 总是先运行ANALYZE。

该命令将会收集表中数值分布状况的统计。在估算一个查询返回的行数时需要这个信息，而规划器则需要这个行数以便给每个可能的查询规划赋予真实的开销值。如果缺乏任何真实的统计信息，那么就会使用一些缺省数值，这样肯定是不准确的。因此，如果还没有运行ANALYZE就检查一个索引的使用状况，那将会是一次失败的检查。

2. 使用真实的数据做实验。

用测试数据填充数据表，那么该表的索引将只会基于测试数据来评估该如何使用索引，而不是对所有的数据都如此使用。比如从100000行中选1000行，规划器可能会考虑使用索引，那么如果从100行中选1行就很难说也会使用索引了。因为100行的数据很可能是存储在一个磁盘页面中，然而没有任何查询规划能比通过顺序访问一个磁盘页面更加高效了。与此同时，在模拟测试数据时也要注意，如果这些数据是非常相似的数据、完全随机的数据，或按照排序顺序插入的数据，都会令统计信息偏离实际数据应该具有的特征。

3. 如果索引没有得到使用，那么在测试中强制它的使用也许会有些价值。有一些运行时参数可以关闭各种各样的查询规划。

4. 强制使用索引用法将会导致两种可能：一是系统选择是正确的，使用索引实际上并不合适，二是查询计划的开销计算并不能反映现实情况。这样你就应该对使用和不使用索引的查询进行计时，这个时候EXPLAIN ANALYZE命令就很有用了。

讨论PostgreSQL 和其他数据库的差异在哪里

一、 PostgreSQL 的稳定性极强， Innodb 等引擎在崩溃、断电之类的灾难场景下抗打击能力有了长足进步，然而很多 MySQL 用户都遇到过Server级的数据库丢失的场景——mysql系统库是MyISAM的，相比之下，PG数据库这方面要好一些。

二、任何系统都有它的性能极限，在高并发读写，负载逼近极限下，PG的性能指标仍可以维持双曲线甚至对数曲线，到顶峰之后不再下降，而 MySQL 明显出现一个波峰后下滑（5.5版本之后，在企业级版本中有个插件可以改善很多，不过需要付费）。

三、PG 多年来在 GIS 领域处于优势地位，因为它有丰富的几何类型，实际上不止几何类型，PG有大量字典、数组、bitmap 等数据类型，相比之下mysql就差很多，instagram就是因为PG的空间数据库扩展POSTGIS远远强于MYSQL的my spatial而采用PGSQL的。

四、PG 的“无锁定”特性非常突出，甚至包括 vacuum 这样的整理数据空间的操作，这个和PGSQL的MVCC实现有关系。

五、PG 的可以使用函数和条件索引，这使得PG数据库的调优非常灵活，mysql就没有这个功能，条件索引在web应用中很重要。

若要玩转大数据，在什么应用场景使用Hadoop，PostgreSQL

您好，1）用户实用程序：

createdb 创建一个新的PostgreSQL的数据库（和SQL语句：CREATE database 相同）

createuser 创建一个新的PostgreSQL的用户（和SQL语句：CREATE USER 相同）

dropdb 删除数据库

dropuser 删除用户

pg_dump 将PostgreSQL数据库导出到一个脚本文件

pg_dumpall 将所有的PostgreSQL数据库导出到一个脚本文件

pg_restore 从一个由pg_dump或pg_dumpall程序导出的脚本文件中恢复PostgreSQL数据库

psql 一个基于命令行的PostgreSQL交互式客户端程序

vacuumdb 清理和分析一个PostgreSQL数据库，它是客户端程序psql环境下SQL语句VACUUM的shell脚本封装，二者功能完全相同

（2）系统实用程序

initdb 创建一个用于存储数据库的PostgreSQL数据目录，并创建预定义的模板数据库template0和template1,生成共享目录表 catalog；此程序通常只在安装PostgreSQL时运行一次

initlocation 创建一个辅助的PostgreSQL数据库存储区域

ipcclean 从停止的PostgreSQL服务器中清除共享内在和孤立信号标志

pg_ctl 启动、停止、重启PostgreSQL服务（比如：pg_ctl start 启动PostgreSQL服务，它和service postgresql start相同）

pg_controldata 显示PostgreSQL服务的内部控制信息

postgres PostgreSQL单用户模式的数据库服务

postmaster PostgreSQL多用户模式的数据库服务

4.这里面最重要的是psql这个客户端程序最为重要。启用客户端程序psql的方法是：

切换到PostgreSQL预定义的数据库超级用户postgres，启用客户端程序psql，并连接到自己想要的数据库，比如说：

psql template1

出现以下界面，说明已经进入到想要的数据库，可以进行想要的操作了。

template1=#

5.在数据库中的一些命令：

template1=# \l 查看系统中现存的数据库

template1=# \q 退出客户端程序psql

template1=# \c 从一个数据库中转到另一个数据库中，如template1=# \c sales 从template1转到sales

template1=# \dt 查看表

template1=# \d 查看表结构

template1=# \di 查看索引

6.要注意随时对数据库进行清理、收回磁盘空间并更新统计信息，使用下面的命令就搞定！

vaccumdb -d sales -z

-a 对所有的数据库操作

-z 保证不断地删除失效的行，节约磁盘空间，将统计信息更新为最近的状态

7.PostgreSQL用户认证

PostgreSQL数据目录中的pg_hba.conf的作用就是用户认证，可以在/var/lib/pgsql/data中找到。

有以下几个例子可以看看：

(1)允许在本机上的任何身份连接任何数据库

TYPE database USER IP-addRESS IP-MASK method

local all all trust(无条件进行连接)

(2)允许IP地址为192.168.1.x的任何主机与数据库sales连接

TYPE database USER IP-addRESS IP-MASK method

host sales all 192.168.1.0 255.255.255.0 ident sameuser(表明任何操作系统用户都能够以同名数据库用户进行连接)

8.看了那么多，来一个完整的创建PostgreSQL数据库用户的示例吧

(1)进入PostgreSQL高级用户

(2)启用客户端程序，并进入template1数据库

psql template1

(3)创建用户

template1=# CREATE USER hellen WITH ENCRYPED password'zhenzhen'

(4)因为设置了密码，所以要编辑pg_hba.conf，使用户和配置文件同步。

在原有记录上面添加md5

local all hellen md5

(4)使用新用户登录数据库

template1=# \q

psql -U hellen -d template1

PS：在一个数据库中如果要切换用户，要使用如下命令：

template1=# \!psql -U tk -d template1

9.设定用户特定的权限

还是要用例子来说明：

创建一个用户组：

sales=# CREATE group sale;

添加几个用户进入该组

sales=# alter group sale add USER sale1,sale2,sale3;

授予用户级sale针对表employee和products的select权限

sales=# grant select on employee,products TO group sale;

在sale中将用户user2删除

sales=# alter GROP sale DROP USER sale2;

10.备份数据库

可以使用pg_dump和pg_dumpall来完成。比如备份sales数据库：

pg_dump sales/home/tk/pgsql/backup/1.bak

借助Postgresql生成热力图

热力图，在空间数据可视化场景中是一个非常常见的需求。首先看下一个完整的热力图效果。

前端实现热力图的原理可以看该 博文 。本文不是探究热力图前端实现原理的，是来探讨由于热力图一次性加载的点过多，产生卡顿的问题。

前面的 博文 也提出了自己的解决办法。但是若数据居多（10w+）,光数据传输就头疼。现有的热力图的前端组件有很多，可以用openlayer、高德地图js、百度地图js、mapbox等。但是大多数的数据结构的都是下面这种形式。

所以需要在后台将下面策略实现，给前台页面传输合适的数据就行。

借助postgresql的width_bucket和postgis，仅用0.4s将20W的数据压缩到2500，这就大大降低了数据传输和渲染的压力。同时也不需要对已有的GIS前端热力图组件进行修改。

德哥的文章

数据可视化：浅谈热力图如何在前端实现

postgreSQL的简单介绍？

postgreSQL是一款先进的开源数据库，拥有非常齐全的自由软件的对象-关系型数据库管理系统（ORDBMS），可面向企业复杂SQL的OLTP业务场景，支持多项企业级功能，能解决使用数据库的各种难题。

PostgreSQL的优势有很多。它是一个免费的对象-关系数据库服务器(ORDBMS)，在灵活的BSD许可证下发行。

postgreSQL的特征

函数：通过函数，可以在数据库服务器端执行指令程序。

索引：用户可以自定义索引方法，或使用内置的 B 树，哈希表与 GiST 索引。

触发器：触发器是由SQL语句查询所触发的事件。如：一个INSERT语句可能触发一个检查数据完整性的触发器。触发器通常由INSERT或UPDATE语句触发。 多版本并发控制：PostgreSQL使用多版本并发控制（MVCC，Multiversion concurrency control）系统进行并发控制，该系统向每个用户提供了一个数据库的"快照"，用户在事务内所作的每个修改，对于其他的用户都不可见，直到该事务成功提交。

规则：规则（RULE）允许一个查询能被重写，通常用来实现对视图（VIEW）的操作，如插入（INSERT）、更新（UPDATE）、删除（DELETE）。

数据类型：包括文本、任意精度的数值数组、JSON 数据、枚举类型、XML 数据等。全文检索：通过 Tsearch2 或 OpenFTS，8.3版本中内嵌 Tsearch2。

NoSQL：JSON，JSONB，XML，HStore 原生支持，至 NoSQL 数据库的外部数据包装器。

数据仓库：能平滑迁移至同属postgreSQL生态的GreenPlum，DeepGreen，HAWK 等，使用 FDW 进行 ETL。

文章标题：关于postgresql场景的信息
文章起源：http://pwwzsj.com/article/dsdhccc.html