为什么postgrelsql的性能没有mysql好

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

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

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

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

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

六、PG有极其强悍的 SQL 编程能力（9x 图灵完备，支持递归！），有非常丰富的统计函数和统计语法支持，比如分析函数（ORACLE的叫法，PG里叫window函数），还可以用多种语言来写存储过程，对于R的支持也很好。这一点上MYSQL就差的很远，很多分析功能都不支持，腾讯内部数据存储主要是MYSQL，但是数据分析主要是HADOOP+PGSQL。

七、PG 的有多种集群架构可以选择，plproxy 可以支持语句级的镜像或分片，slony 可以进行字段级的同步设置，standby 可以构建WAL文件级或流式的读写分离集群，同步频率和集群策略调整方便， *** 作非常简单。

八、一般关系型数据库的字符串有限定长度8k左右，无限长 TEXT 类型的功能受限，只能作为外部大数据访问。而 PG 的 TEXT 类型可以直接访问，SQL语法内置正则表达式，可以索引，还可以全文检索，或使用xml xpath。用PG的话，文档数据库都可以省了。

九，对于WEB应用来说，复制的特性很重要，mysql到现在也是异步复制，pgsql可以做到同步，异步，半同步复制。还有mysql的同步是基于binlog复制，类似oracle golden gate,是基于stream的复制，做到同步很困难，这种方式更加适合异地复制，pgsql的复制基于wal，可以做到同步复制。同时，pgsql还提供stream复制。

十，pgsql对于numa架构的支持比mysql强一些，比MYSQL对于读的性能更好一些，pgsql提交可以完全异步，而mysql的内存表不够实用（因为表锁的原因）

最后说一下我感觉 PG 不如 MySQL 的地方。

第一，MySQL有一些实用的运维支持，如 slow-querylog ，这个pg肯定可以定制出来，但是如果可以配置使用就更好了。

第二是mysql的innodb引擎，可以充分优化利用系统所有内存，超大内存下PG对内存使用的不那么充分，

第三点，MySQL的复制可以用多级从库，但是在92之前，PGSQL不能用从库带从库。

第四点，从测试结果上看，mysql 55的性能提升很大，单机性能强于pgsql，56应该会强更多

第五点，对于web应用来说,mysql 56 的内置MC API功能很好用，PGSQL差一些。

另外一些：

pgsql和mysql都是背后有商业公司，而且都不是一个公司。大部分开发者，都是拿工资的。

说mysql的执行速度比pgsql快很多是不对的，速度接近，而且很多时候取决于你的配置。

对于存储过程，函数，视图之类的功能，现在两个数据库都可以支持了。

另外多线程架构和多进程架构之间没有绝对的好坏，oracle在unix上是多进程架构，在windows上是多线程架构。

很多pg应用也是24/7的应用，比如skype 最近几个版本VACUUM基本不影响PGSQL 运行，80之后的PGSQL不需要cygwin就可以在windows上运行。

至于说对于事务的支持，mysql和pgsql都没有问题。

特性 MySQL PostgreSQL

实例 通过执行 MySQL 命令（mysqld）启动实例。一个实例可以管理一个或多个数据库。一台服务器可以运行多个 mysqld 实例。一个实例管理器可以监视 mysqld 的各个实例。

通过执行 Postmaster 进程（pg_ctl）启动实例。一个实例可以管理一个或多个数据库，这些数据库组成一个集群。集群是磁盘上的一个区域，这个区域在安装时初始化并由一个目录组成，所有数据都存储在这个目录中。使用 initdb 创建第一个数据库。一台机器上可以启动多个实例。

数据库 数据库是命名的对象集合，是与实例中的其他数据库分离的实体。一个 MySQL 实例中的所有数据库共享同一个系统编目。 数据库是命名的对象集合，每个数据库是与其他数据库分离的实体。每个数据库有自己的系统编目，但是所有数据库共享 pg_databases。

数据缓冲区 通过 innodb_buffer_pool_size 配置参数设置数据缓冲区。这个参数是内存缓冲区的字节数，InnoDB 使用这个缓冲区来缓存表的数据和索引。在专用的数据库服务器上，这个参数最高可以设置为机器物理内存量的 80%。 Shared_buffers 缓存。在默认情况下分配 64 个缓冲区。默认的块大小是 8K。可以通过设置 postgresqlconf 文件中的 shared_buffers 参数来更新缓冲区缓存。

数据库连接 客户机使用 CONNECT 或 USE 语句连接数据库，这时要指定数据库名，还可以指定用户 id 和密码。使用角色管理数据库中的用户和用户组。 客户机使用 connect 语句连接数据库，这时要指定数据库名，还可以指定用户 id 和密码。使用角色管理数据库中的用户和用户组。

身份验证 MySQL 在数据库级管理身份验证。 基本只支持密码认证。 PostgreSQL 支持丰富的认证方法：信任认证、口令认证、Kerberos 认证、基于 Ident 的认证、LDAP 认证、PAM 认证

加密 可以在表级指定密码来对数据进行加密。还可以使用 AES_ENCRYPT 和 AES_DECRYPT 函数对列数据进行加密和解密。可以通过 SSL 连接实现网络加密。 可以使用 pgcrypto 库中的函数对列进行加密/解密。可以通过 SSL 连接实现网络加密。

审计 可以对 querylog 执行 grep。 可以在表上使用 PL/pgSQL 触发器来进行审计。

查询解释 使用 EXPLAIN 命令查看查询的解释计划。 使用 EXPLAIN 命令查看查询的解释计划。

备份、恢复和日志 InnoDB 使用写前（write-ahead）日志记录。支持在线和离线完全备份以及崩溃和事务恢复。需要第三方软件才能支持热备份。 在数据目录的一个子目录中维护写前日志。支持在线和离线完全备份以及崩溃、时间点和事务恢复。 可以支持热备份。

JDBC 驱动程序 可以从 参考资料 下载 JDBC 驱动程序。 可以从 参考资料 下载 JDBC 驱动程序。

表类型 取决于存储引擎。例如，NDB 存储引擎支持分区表，内存引擎支持内存表。 支持临时表、常规表以及范围和列表类型的分区表。不支持哈希分区表。 由于PostgreSQL的表分区是通过表继承和规则系统完成了，所以可以实现更复杂的分区方式。

索引类型 取决于存储引擎。MyISAM：BTREE，InnoDB：BTREE。 支持 B-树、哈希、R-树和 Gist 索引。

约束 支持主键、外键、惟一和非空约束。对检查约束进行解析，但是不强制实施。 支持主键、外键、惟一、非空和检查约束。

存储过程和用户定义函数 支持 CREATE PROCEDURE 和 CREATE FUNCTION 语句。存储过程可以用 SQL 和 C++ 编写。用户定义函数可以用 SQL、C 和 C++ 编写。 没有单独的存储过程，都是通过函数实现的。用户定义函数可以用 PL/pgSQL（专用的过程语言）、PL/Tcl、PL/Perl、PL/Python 、SQL 和 C 编写。

触发器 支持行前触发器、行后触发器和语句触发器，触发器语句用过程语言复合语句编写。 支持行前触发器、行后触发器和语句触发器，触发器过程用 C 编写。

系统配置文件 myconf Postgresqlconf

数据库配置 myconf Postgresqlconf

客户机连接文件 myconf pg_hbaconf

XML 支持 有限的 XML 支持。 有限的 XML 支持。

数据访问和管理服务器 OPTIMIZE TABLE —— 回收未使用的空间并消除数据文件的碎片

myisamchk -analyze —— 更新查询优化器所使用的统计数据（MyISAM 存储引擎）

mysql —— 命令行工具

MySQL Administrator —— 客户机 GUI 工具 Vacuum —— 回收未使用的空间

Analyze —— 更新查询优化器所使用的统计数据

psql —— 命令行工具

pgAdmin —— 客户机 GUI 工具

并发控制 支持表级和行级锁。InnoDB 存储引擎支持 READ_COMMITTED、READ_UNCOMMITTED、REPEATABLE_READ 和 SERIALIZABLE。使用 SET TRANSACTION ISOLATION LEVEL 语句在事务级设置隔离级别。 支持表级和行级锁。支持的 ANSI 隔离级别是 Read Committed（默认 —— 能看到查询启动时数据库的快照）和 Serialization（与 Repeatable Read 相似 —— 只能看到在事务启动之前提交的结果）。使用 SET TRANSACTION 语句在事务级设置隔离级别。使用 SET SESSION 在会话级进行设置。

MySQL相对于PostgreSQL的劣势：

MySQL

PostgreSQL

最重要的引擎InnoDB很早就由Oracle公司控制。目前整个MySQL数据库都由Oracle控制。

BSD协议，没有被大公司垄断。

对复杂查询的处理较弱，查询优化器不够成熟

很强大的查询优化器，支持很复杂的查询处理。

只有一种表连接类型:嵌套循环连接(nested-loop),不支持排序-合并连接(sort-merge join)与散列连接(hash join)。

都支持

性能优化工具与度量信息不足

提供了一些性能视图，可以方便的看到发生在一个表和索引上的select、delete、update、insert统计信息，也可以看到cache命中率。网上有一个开源的pgstatspack工具。

InnoDB的表和索引都是按相同的方式存储。也就是说表都是索引组织表。这一般要求主键不能太长而且插入时的主键最好是按顺序递增，否则对性能有很大影响。

不存在这个问题。

大部分查询只能使用表上的单一索引;在某些情况下，会存在使用多个索引的查询,但是查询优化器通常会低估其成本,它们常常比表扫描还要慢。

不存在这个问题

表增加列，基本上是重建表和索引，会花很长时间。

表增加列，只是在数据字典中增加表定义，不会重建表

存储过程与触发器的功能有限。可用来编写存储过程、触发器、计划事件以及存储函数的语言功能较弱

除支持pl/pgsql写存储过程，还支持perl、python、Tcl类型的存储过程：pl/perl，pl/python，pl/tcl。

也支持用C语言写存储过程。

不支持Sequence。

支持

不支持函数索引，只能在创建基于具体列的索引。

不支持物化视图。

支持函数索引，同时还支持部分数据索引，通过规则系统可以实现物化视图的功能。

执行计划并不是全局共享的, 仅仅在连接内部是共享的。

执行计划共享

MySQL支持的SQL语法(ANSI SQL标准)的很小一部分。不支持递归查询、通用表表达式（Oracle的with 语句）或者窗口函数（分析函数）。

都 支持

不支持用户自定义类型或域(domain)

支持。

对于时间、日期、间隔等时间类型没有秒以下级别的存储类型

可以精确到秒以下。

身份验证功能是完全内置的，不支持 *** 作系统认证、PAM认证，不支持LDAP以及其它类似的外部身份验证功能。

支持OS认证、Kerberos 认证 、Ident 的认证、LDAP 认证、PAM 认证

不支持database link。有一种叫做Federated的存储引擎可以作为一个中转将查询语句传递到远程服务器的一个表上,不过,它功能很粗糙并且漏洞很多

有dblink，同时还有一个dbi-link的东西，可以连接到oracle和mysql上。

Mysql Cluster可能与你的想象有较大差异。开源的cluster软件较少。

复制(Replication)功能是异步的,并且有很大的局限性例如,它是单线程的(single-threaded),因此一个处理能力更强的Slave的恢复速度也很难跟上处理能力相对较慢的Master

有丰富的开源cluster软件支持。

explain看执行计划的结果简单。

explain返回丰富的信息。

类似于ALTER TABLE或CREATE TABLE一类的 *** 作都是非事务性的它们会提交未提交的事务，并且不能回滚也不能做灾难恢复

DDL也是有事务的。

PostgreSQL主要优势：

1 PostgreSQL完全免费，而且是BSD协议，如果你把PostgreSQL改一改，然后再拿去卖钱，也没有人管你，这一点很重要，这表明了PostgreSQL数据库不会被其它公司控制。oracle数据库不用说了，是商业数据库，不开放。而MySQL数据库虽然是开源的，但现在随着SUN被oracle公司收购，现在基本上被oracle公司控制，其实在SUN被收购之前，MySQL中最重要的InnoDB引擎也是被oracle公司控制的，而在MySQL中很多重要的数据都是放在InnoDB引擎中的，反正我们公司都是这样的。所以如果MySQL的市场范围与oracle数据库的市场范围冲突时，oracle公司必定会牺牲MySQL，这是毫无疑问的。

2 与PostgreSQl配合的开源软件很多，有很多分布式集群软件，如pgpool、pgcluster、slony、plploxy等等，很容易做读写分离、负载均衡、数据水平拆分等方案，而这在MySQL下则比较困难。

3 PostgreSQL源代码写的很清晰，易读性比MySQL强太多了，怀疑MySQL的源代码被混淆过。所以很多公司都是基本PostgreSQL做二次开发的。

4 PostgreSQL在很多方面都比MySQL强，如复杂SQL的执行、存储过程、触发器、索引。同时PostgreSQL是多进程的，而MySQL是线程的，虽然并发不高时，MySQL处理速度快，但当并发高的时候，对于现在多核的单台机器上，MySQL的总体处理性能不如PostgreSQL，原因是MySQL的线程无法充分利用CPU的能力。

目前只想到这些，以后想到再添加，欢迎大家拍砖。

PostgreSQL与oracle或InnoDB的多版本实现的差别

PostgreSQL与oracle或InnoDB的多版本实现最大的区别在于最新版本和历史版本是否分离存储，PostgreSQL不分，而oracle和InnoDB分，而innodb也只是分离了数据,索引本身没有分开。

PostgreSQL的主要优势在于：

1 PostgreSQL没有回滚段，而oracle与innodb有回滚段，oracle与Innodb都有回滚段。对于oracle与Innodb来说，回滚段是非常重要的，回滚段损坏，会导致数据丢失，甚至数据库无法启动的严重问题。另由于PostgreSQL没有回滚段，旧数据都是记录在原先的文件中，所以当数据库异常crash后，恢复时，不会象oracle与Innodb数据库那样进行那么复杂的恢复，因为oracle与Innodb恢复时同步需要redo和undo。所以PostgreSQL数据库在出现异常crash后，数据库起不来的几率要比oracle和mysql小一些。

2 由于旧的数据是直接记录在数据文件中，而不是回滚段中，所以不会象oracle那样经常报ora-01555错误。

3 回滚可以很快完成，因为回滚并不删除数据，而oracle与Innodb，回滚时很复杂，在事务回滚时必须清理该事务所进行的修改，插入的记录要删除，更新的记录要更新回来(见row_undo函数)，同时回滚的过程也会再次产生大量的redo日志。

4 WAL日志要比oracle和Innodb简单，对于oracle不仅需要记录数据文件的变化，还要记录回滚段的变化。

PostgreSQL的多版本的主要劣势在于：

1、最新版本和历史版本不分离存储，导致清理老旧版本需要作更多的扫描，代价比较大，但一般的数据库都有高峰期，如果我们合理安排VACUUM，这也不是很大的问题，而且在PostgreSQL90中VACUUM进一步被加强了。

2、由于索引中完全没有版本信息，不能实现Coverage index scan，即查询只扫描索引，直接从索引中返回所需的属性，还需要访问表。而oracle与Innodb则可以;

进程模式与线程模式的对比

PostgreSQL和oracle是进程模式，MySQL是线程模式。

进程模式对多CPU利用率比较高。

进程模式共享数据需要用到共享内存，而线程模式数据本身就是在进程空间内都是共享的，不同线程访问只需要控制好线程之间的同步。

线程模式对资源消耗比较少。

所以MySQL能支持远比oracle多的更多的连接。

对于PostgreSQL的来说，如果不使用连接池软件，也存在这个问题，但PostgreSQL中有优秀的连接池软件软件，如pgbouncer和pgpool，所以通过连接池也可以支持很多的连接。

堆表与索引组织表的的对比

Oracle支持堆表，也支持索引组织表

PostgreSQL只支持堆表，不支持索引组织表

Innodb只支持索引组织表

索引组织表的优势：

表内的数据就是按索引的方式组织，数据是有序的，如果数据都是按主键来访问，那么访问数据比较快。而堆表，按主键访问数据时，是需要先按主键索引找到数据的物理位置。

索引组织表的劣势：

索引组织表中上再加其它的索引时，其它的索引记录的数据位置不再是物理位置，而是主键值，所以对于索引组织表来说，主键的值不能太大，否则占用的空间比较大。

对于索引组织表来说，如果每次在中间插入数据，可能会导致索引分裂，索引分裂会大大降低插入的性能。所以对于使用innodb来说，我们一般最好让主键是一个无意义的序列，这样插入每次都发生在最后，以避免这个问题。

由于索引组织表是按一个索引树，一般它访问数据块必须按数据块之间的关系进行访问，而不是按物理块的访问数据的，所以当做全表扫描时要比堆表慢很多，这可能在OLTP中不明显，但在数据仓库的应用中可能是一个问题。

　 PostgreSQL90中的特色功能：

PostgreSQL中的Hot Standby功能

也就是standby在应用日志同步时，还可以提供只读服务，这对做读写分离很有用。这个功能是oracle11g才有的功能。

PostgreSQL异步提交（Asynchronous Commit）的功能：

　 这个功能oracle中也是到oracle11g R2才有的功能。因为在很多应用场景中，当宕机时是允许丢失少量数据的，这个功能在这样的场景中就特别合适。在PostgreSQL90中把synchronous_commit设置为false就打开了这个功能。需要注意的是，虽然设置为了异步提交，当主机宕机时，PostgreSQL只会丢失少量数据，异步提交并不会导致数据损坏而数据库起不来的情况。MySQL中没有听说过有这个功能。

PostgreSQL中索引的特色功能：

PostgreSQL中可以有部分索引，也就是只能表中的部分数据做索引，create index 可以带where 条件。同时PostgreSQL中的索引可以反向扫描，所以在PostgreSQL中可以不必建专门的降序索引了。

PostgresSQL提供了许多数据库配置参数，本章将介绍每个参数的作用和如何配置每一个参数。

101 如何设置数据库参数

所有的参数的名称都是不区分大小写的。每个参数的取值是布尔型、整型、浮点型和字符串型这四种类型中的一个，分别用boolean

、integer、 floating point和string表示。布尔型的值可以写成ON、OFF、 TRUE、 FALSE、 YES、 NO、 1和 0，而且不区分大小

写。

有些参数用来配置内存大小和时间值。内存大小的单位可以是KB、MB和GB。时间的单位可以是毫秒、秒、分钟、小时和天。用ms表示

毫秒，用s表示秒，用 min表示分钟，用h表示小时，用d表示天。表示内存大小和时间值的参数参数都有一个默认的单位，如果用户

在设置参数的值时没有指定单位，则以参数默认的 单位为准。例如，参数shared_buffers表示数据缓冲区的大小，它的默认单位是

数据块的个数，如果把它的值设成8，因为每个数据块的大小是 8KB，则数据缓冲区的大小是88=64KB，如果将它的值设成128MB，

则数据缓冲区的大小是128MB。参数vacuum_cost_delay 的默认单位是毫秒，如果把它的值设成10，则它的值是10毫秒，如果把它的

值设成100s，则它的值是100秒。

所有的参数都放在文件 postgresqlconf中，下面是一个文件实例:

#这是注释

log_connections = yes

log_destination = 'syslog'

search_path = '"$user", public'

每一行只能指定一个参数，空格和空白行都会被忽略。“ #”表示注释，注释信息不用单独占一行，可以出现在配置文件的任何地方

。如果参数的值不是简单的标识符和数字，应该用单引号引起来。如果参数的值中有单引号，应该写两个单引号，或者在单引号前面

加一个反斜杠。

一个配置文件也可以包含其它配置文件，使用include指令能够达到这个目的，例如，假设postgresqlconf文件中有下面一行：

include ‘myconfg’

文件myconfig中的配置信息也会被数据库读入。include指令指定的配置文件也可以用include指令再包含其它配置文件。如果

include指令中指定的文件名不是绝对路径，数据库会在postgresqlconf文件所在的目录下查找这个文件。

用户也可以在数据库启动以后修改postgresqlconf配置文件，使用命令pg_ctl reload来通知数据库重新读取配置文件。注意，有些

参数在数据库启动以后，不能被修改，只有重新启动数据库以后，新的参数值才能生效。另外一些参数可 以在数据库运行过程中被

修改而且新的值可以立即生效。所以数据库在运行过程中重新读取参数配置文件以后，不是所有的参数都会被赋给新的值。

用户可以在自己建立的会话中执行命令SET修改某些配置参数的值（注意不是全部参数），例如：

SET ENABLE_SEQSCAN TO OFF;

另外，有些参数只有数据库超级用户才能使用SET命令修改它们。用户可以在psql中执行命令show来查看所有的数据库参数的当前值

。例如：

（1）show all; --查看所有数据库参数的值

（2）show search_path; --查看参数search_path的值

102 连接与认证

1021 连接设置

listen_addresses (string)

这个参数只有在启动数据库时，才能被设置。它指定数据库用来监听客户端连接的TCP/IP地址。默认是值是 ，表示数据库在启动以

后将在运行数据的机器上的所有的IP地址上监听用户请求（如果机器只有一个网卡，只有一个IP地址，有多个网卡的机器有多个 IP

地址）。可以写成机器的名字，也可以写成IP地址，不同的值用逗号分开，例如，’server01’, ’1408717149, 1408717121

’。如果被设成localhost，表示数据库只能接受本地的客户端连接请求，不能接受远程的客户端连接请求。

port (integer)

这个参数只有在启动数据库时，才能被设置。它指定数据库监听户端连接的TCP端口。默认值是5432。

max_connections (integer)

这个参数只有在启动数据库时，才能被设置。它决定数据库可以同时建立的最大的客户端连接的数目。默认值是100。

superuser_reserved_connections (integer)

这个参数只有在启动数据库时，才能被设置。它表示预留给超级用户的数据库连接数目。它的值必须小于max_connections。 普通用

户可以在数据库中建立的最大的并发连接的数目是max_connections- superuser_reserved_connections， 默认值是3。

unix_socket_group (string)

这个参数只有在启动数据库时，才能被设置。设置Unix-domain socket所在的 *** 作系统用户组。默认值是空串，用启动数据库的 *** 作

系统用户所在的组作为Unix-domain socket的用户组。

unix_socket_permissions (integer)

这个参数只有在启动数据库时，才能被设置。它设置Unix-domain socket的访问权限，格式与 *** 作系统的文件访问权限是一样的。默

认值是0770，表示任何 *** 作系统用户都能访问Unix-domain socket。可以设为0770（所有Unix-domain socket文件的所有者所在的组

包含的用户都能访问）和0700(只有Unix-domain socket文件的所有者才能访问)。对于Unix-domain socket，只有写权限才有意义，

读和执行权限是没有意义的。

tcp_keepalives_idle (integer)

这个参数可以在任何时候被设置。默认值是0，意思是使用 *** 作系统的默认值。它设置TCP套接字的TCP_KEEPIDLE属性。这个参数对于

通过Unix-domain socket建立的数据库连接没有任何影响。

tcp_keepalives_interval (integer)

这个参数可以在任何时候被设置。默认值是0，意思是使用 *** 作系统的默认值。它设置TCP套接字的TCP_KEEPINTVL属性。这个参数对

于通过Unix-domain socket建立的数据库连接没有任何影响。

tcp_keepalives_count (integer)

这个参数可以在任何时候被设置。默认值是0，意思是使用 *** 作系统的默认值。它设置TCP套接字的TCP_KEEPCNT属性。这个参数对于

通过Unix-domain socket建立的数据库连接没有任何影响。

1022 安全与认证

authentication_timeout (integer)

这个参数只能在postgresqlconf文件中被设置，它指定一个时间长度，在这个时间长度内，必须完成客户端认证 *** 作，否则客户端

连接请求将被拒绝。它可以阻止某些客户端进行认证时长时间占用数据库连接。单位是秒，默认值是60。

ssl (boolean)

这个参数只有在启动数据库时，才能被设置。决定数据库是否接受SSL连接。默认值是off。

ssl_ciphers (string)

指定可以使用的SSL加密算法。查看 *** 作系统关于openssl的用户手册可以得到完整的加密算法列表（执行命令openssl ciphers –v

也可以得到）。

103 资源消耗

1031 内存

shared_buffers (integer)

这个参数只有在启动数据库时，才能被设置。它表示数据缓冲区中的数据块的个数，每个数据块的大小是8KB。数据缓冲区位于数据

库的共享内存中，它越大越好，不能小于128KB。默认值是1024。

temp_buffers (integer)

这个参数可以在任何时候被设置。默认值是8MB。它决定存放临时表的数据缓冲区中的数据块的个数，每个数据块的大小是8KB。临时

表缓冲区存放在每个数据库进程的私有内存中，而不是存放在数据库的共享内存中。默认值是1024。

max_prepared_transactions (integer)

这个参数只有在启动数据库时，才能被设置。它决定能够同时处于prepared状态的事务的最大数目（参考PREPARE TRANSACTION命令

）。如果它的值被设为0。则将数据库将关闭prepared事务的特性。它的值通常应该和max_connections的值 一样大。默认值是5。

work_mem (integer)

这个参数可以在任何时候被设置。它决定数据库的排序 *** 作和哈希表使用的内存缓冲区的大小。如何work_mem指定的内存被耗尽，数

据库将使用磁盘文件进 行完成 *** 作，速度会慢很多。ORDER BY、DISTINCT和merge连接会使用排序 *** 作。哈希表在Hash连接、hash聚

集函数和用哈希表来处理IN谓词中的子查询中被使用。单位是 KB，默认值是1024。

maintenance_work_mem (integer)

这个参数可以在任何时候被设置。它决定数据库的维护 *** 作使用的内存空间的大小。数据库的维护 *** 作包括VACUUM、CREATE INDEX和

ALTER TABLE ADD FOREIGN KEY等 *** 作。 maintenance_work_mem的值如果比较大，通常可以缩短VACUUM数据库和从dump文件中恢复数

据库需要的时间。 maintenance_work_mem存放在每个数据库进程的私有内存中，而不是存放在数据库的共享内存中。单位是KB，默

认值是16384。

max_stack_depth (integer)

这个参数可以在任何时候被设置，但只有数据库超级用户才能修改它。它决定一个数据库进程在运行时的STACK所占的空间的最大值

。数据库进程在运行时，会 自动检查自己的STACK大小是否超过max_stack_depth，如果超过，会自动终止当前事务。这个值应该比

*** 作系统设置的进程STACK的大小 的上限小1MB。使用 *** 作系统命令“ulimit –s“可以得到 *** 作系统设置的进程STACK的最大值。单

位是KB，默认值是100。

1032 Free Space Map

数据库的所有可用空间信息都存放在一个叫free space map (FSM)的结构中，它记载数据文件中每个数据块的可用空间的大小。FSM

中没有记录的数据块，即使有可用空间，也不会系统使用。系统如果需要新的物理存 储空间，会首先在FSM中查找，如果FSM中没有

一个数据页有足够的可用空间，系统就会自动扩展数据文件。所以，FSM如果太小，会导致系统频繁地扩展数 据文件，浪费物理存储

空间。命令VACUUM VERBOSE在执行结束以后，会提示当前的FSM设置是否满足需要，如果FSM的参数值太小，它会提示增大参数。

FSM存放在数据库的共享内存中，由于物理内存的限制，FSM不可能跟踪数据库的所有的数据文件的所有数据块的可用空间信息，只能

跟踪一部分数据块的可用空间信息。

max_fsm_relations (integer)

这个参数只有在启动数据库时，才能被设置。默认值是1000。它决定FSM跟踪的表和索引的个数的上限。每个表和索引在FSM中占7个

字节的存储空间。

max_fsm_pages (integer)

这个参数只有在启动数据库时，才能被设置。它决定FSM中跟踪的数据块的个数的上限。initdb在创建数据库集群时会根据物理内存

的大小决定它的值。每 个数据块在fsm中占6个字节的存储空间。它的大小不能小于16 max_fsm_relations。默认值是20000。

1033 内核资源

max_files_per_process (integer)

这个参数只有在启动数据库时，才能被设置。他设定每个数据库进程能够打开的文件的数目。默认值是1000。

shared_preload_libraries (string)

这个参数只有在启动数据库时，才能被设置。它设置数据库在启动时要加载的 *** 作系统共享库文件。如果有多个库文件，名字用逗号

分开。如果数据库在启动时未找到shared_preload_libraries指定的某个库文件，数据库将无法启动。默认值为空串。

1034 垃圾收集

执行VACUUM 和ANALYZE命令时，因为它们会消耗大量的CPU与IO资源，而且执行一次要花很长时间，这样会干扰系统执行应用程序发

出的SQL命令。为了解决这个 问题，VACUUM 和ANALYZE命令执行一段时间后，系统会暂时终止它们的运行，过一段时间后再继续执行

这两个命令。这个特性在默认的情况下是关闭的。将参数 vacuum_cost_delay设为一个非零的正整数就可以打开这个特性。

用户通常只需要设置参数vacuum_cost_delay和vacuum_cost_limit，其它的参数使用默认值即可。VACUUM 和ANALYZE命令在执行过程

中，系统会计算它们执行消耗的资源，资源的数量用一个正整数表示，如果资源的数量超过 vacuum_cost_limit，则执行命令的进程

会进入睡眠状态，睡眠的时间长度是是vacuum_cost_delay。 vacuum_cost_limit的值越大，VACUUM 和ANALYZE命令在执行的过程中

，睡眠的次数就越少，反之，vacuum_cost_limit的值越小，VACUUM 和ANALYZE命令在执行的过程中，睡眠的次数就越多。

vacuum_cost_delay (integer)

这个参数可以在任何时候被设置。默认值是0。它决定执行VACUUM 和ANALYZE命令的进程的睡眠时间。单位是微秒。它的值最好是10

的整数，如果不是10的整数，系统会自动将它设为比该值大的并且最接近该值的是10 的倍数的整数。如果值是0，VACUUM 和ANALYZE

命令在执行过程中不会主动进入睡眠状态，会一直执行下去直到结束。

vacuum_cost_page_hit (integer)

这个参数可以在任何时候被设置。默认值是1。

vacuum_cost_page_miss (integer)

这个参数可以在任何时候被设置。默认值是10。

vacuum_cost_page_dirty (integer)

这个参数可以在任何时候被设置。默认值是20。

vacuum_cost_limit (integer)

这个参数可以在任何时候被设置。默认值是200。

1035 后台写数据库进程

后台写数据库进程负责将数据缓冲区中的被修改的数据块（又叫脏数据块）写回到数据库物理文件中。

bgwriter_delay (integer)

这个参数只能在文件postgresqlconf中设置。它决定后台写数据库进程的睡眠时间。后台写数据库进程每次完成写数据到物理文件

中的任务以后， 就会睡眠bgwriter_delay指定的时间。 bgwriter_delay的值应该是10的倍数，如果用户设定的值不是10的倍数，数

据库会自动将参数的值设为比用户指定的值大的最接近用户指定的值 的同时是10的倍数的值。单位是毫秒，默认值是200。

bgwriter_lru_maxpages (integer)

这个参数只能在文件postgresqlconf中设置。默认值是100。后台写数据库进程每次写脏数据块时，写到外部文件中的脏数据块的个

数不能超过 bgwriter_lru_maxpages指定的值。例如，如果它的值是500，则后台写数据库进程每次写到物理文件的数据页的个数不

能超过500，若 超过，进程将进入睡眠状态，等下次醒来再执行写物理文件的任务。如果它的值被设为0, 后台写数据库进程将不会

写任何物理文件（但还会执行检查点 *** 作）。

bgwriter_lru_multiplier (floating point)

这个参数只能在文件postgresqlconf中设置。默认值是20。它决定后台写数据库进程每次写物理文件时，写到外部文件中的脏数据

块的个数 （不能超过bgwriter_lru_maxpages指定的值）。一般使用默认值即可，不需要修改这个参数。这个参数的值越大，后台写

数据库进程每次写 的脏数据块的个数就越多。

104 事务日志

full_page_writes (boolean)

这个参数只能在postgresqlconf文件中被设置。默认值是on。打开这个参数，可以提高数据库的可靠性，减少数据丢失的概率，但

是会产生过多的事务日志，降低数据库的性能。

wal_buffers (integer)

这个参数只有在启动数据库时，才能被设置。默认值是8。它指定事务日志缓冲区中包含的数据块的个数，每个数据块的大小是8KB，

所以默认的事务日志缓冲区的大小是88=64KB。事务日志缓冲区位于数据库的共享内存中。

wal_writer_delay (integer)

这个参数只能在postgresqlconf文件中被设置。它决定写事务日志进程的睡眠时间。WAL进程每次在完成写事务日志的任务后，就会

睡眠 wal_writer_delay指定的时间，然后醒来，继续将新产生的事务日志从缓冲区写到WAL文件中。单位是毫秒（millisecond），

默认 值是200。

commit_delay (integer)

这个参数可以在任何时候被设置。它设定事务在发出提交命令以后的睡眠时间，只有在睡眠了commit_delay指定的时间以后，事务产

生的事务日志才会 被写到事务日志文件中，事务才能真正地提交。增大这个参数会增加用户的等待时间，但是可以让多个事务被同

时提交，提高系统的性能。如果数据库中的负载比较 高，而且大部分事务都是更新类型的事务，可以考虑增大这个参数的值。下面

的参数commit_siblings会影响commit_delay是否生效。 默认值是0，单位是微秒（microsecond）。

commit_siblings (integer)

这个参数可以在任何时候被设置。这个参数的值决定参数commit_delay是否生效。假设commit_siblings的值是5，如果一个事务发出

一个提交请求，此时，如果数据库中正在执行的事务的个数大于或等于5，那么该事务将睡眠commit_delay指定的时间。如果数据库

中正在执行的事务 的个数小于5，这个事务将直接提交。默认值是5。

105 检查点

checkpoint_segments (integer)

这个参数只能在postgresqlconf文件中被设置。默认值是3。它影响系统何时启动一个检查点 *** 作。如果上次检查点 *** 作结束以后，

系统产生的事 务日志文件的个数超过checkpoint_segments的值，系统就会自动启动一个检查点 *** 作。增大这个参数会增加数据库崩

溃以后恢复 *** 作需要的时 间。

checkpoint_timeout (integer)

这个参数只能在postgresqlconf文件中被设置。单位是秒，默认值是300。它影响系统何时启动一个检查点 *** 作。如果现在的时间减

去上次检查 点 *** 作结束的时间超过了checkpoint_timeout的值，系统就会自动启动一个检查点 *** 作。增大这个参数会增加数据库崩

溃以后恢复 *** 作需要的时 间。

checkpoint_completion_target (floating point)

这个参数控制检查点 *** 作的执行时间。合法的取值在0到1之间，默认值是05。不要轻易地改变这个参数的值，使用默认值即可。 这

个参数只能在postgresqlconf文件中被设置。

106 归档模式

archive_mode (boolean)

这个参数只有在启动数据库时，才能被设置。默认值是off。它决定数据库是否打开归档模式。

archive_dir (string)

这个参数只有在启动数据库时，才能被设置。默认值是空串。它设定存放归档事务日志文件的目录。

archive_timeout (integer)

这个参数只能在postgresqlconf文件中被设置。默认值是0。单位是秒。如果archive_timeout的值不是0，而且当前时间减去数 据

库上次进行事务日志文件切换的时间大于archive_timeout的值，数据库将进行一次事务日志文件切换。一般情况下，数据库只有在

一个事务日志 文件写满以后，才会切换到下一个事务日志文件，设定这个参数可以让数据库在一个事务日志文件尚未写满的情况下

切换到下一个事务日志文件。

107 优化器参数

1071 存取方法参数

下列参数控制查询优化器是否使用特定的存取方法。除非对优化器特别了解，一般情况下，使用它们默认值即可。

enable_bitmapscan (boolean)

打开或者关闭bitmap-scan 。默认值是 on。

enable_hashagg (boolean)

打开或者关闭hashed aggregation。默认值是 on。

enable_hashjoin (boolean)

打开或者关闭hash-join。默认值是 on。

enable_indexscan (boolean)

打开或者关闭index-scan。默认值是 on。

enable_mergejoin (boolean)

打开或者关闭merge-join。默认值是 on。

enable_nestloop (boolean)

打开或者关闭nested-loop join。默认值是 on。不可能完全不使用nested-loop join，关闭这个参数会让系统在有其它存取方法可

用的情况下，不使用nested-loop join。

enable_seqscan (boolean)

打开或者关闭sequential scan。默认值是 on。不可能完全不使用sequential scan，关闭这个参数会让系统在有其它存取方法可用

的情况下，不使用sequential scan。

以上就是关于为什么postgrelsql的性能没有mysql好全部的内容，包括:为什么postgrelsql的性能没有mysql好、MySQL与PostgreSQL比较 哪个数据库更好、postgressql数据源怎么配置等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！