Mysql 和 Postgresql(PGSQL) 对比
转载自：http://www.oschina.net/question/96003_13994
PostgreSQL与MySQL比较
MySQL使用太广泛了，以至于我不得不将一些应用从mysql 迁移到postgresql, 很多开源软件都是以Mysql 作为数据库标准，并且以Mysql 作为抽象基础的，但是具体使用过程中，发现Mysql 有很多问题，所以都迁移到postgresql上了，转一个Mysql 和Postgresql 对比的文章：
上是比较容易的，毕竟PostgreSQL数据库与Oracle数据库很相似。
同时，PostgreSQL数据库的源代码要比MySQL数据库的源代码更容易读懂，如果团队的C语言能力比较强的知，就能在PostgreSQL数据库上做开发，比方说实现类似greenplum的系统，这样也能与现在的分布式趋势接轨。
为了说明PostgreSQL的功能，我下面简要对比一下PostgreSQL数据库与MySQL数据库之间的差异：
我们先借助Jametong翻译的"从Oracle迁移到Mysql之前必须知道的50件事"，看一看如何把Oracle转到MySQL中的困难：
50 things to know before migrating Oracle to MySQL
by Baron Schwartz,Translated by Jametong
1. 对子查询的优化表现不佳.
2. 对复杂查询的处理较弱
3. 查询优化器不够成熟
4. 性能优化工具与度量信息不足
5. 审计功能相对较弱
6. 安全功能不成熟,甚至可以说很粗糙.没有用户组与角色的概念,没有回收权限的功能(仅仅可以授予权限).当一个用户从不同的主机/网络以同样地用户名/密码登录之后,可能被当作完全不同的用户来处理.没有类似于Oracle的内置的加密功能.
7. 身份验证功能是完全内置的.不支持LDAP,Active Directory以及其它类似的外部身份验证功能.
8. Mysql Cluster可能与你的想象有较大差异.
9. 存储过程与触发器的功能有限.
10. 垂直扩展性较弱.
11. 不支持MPP(大规模并行处理).
12. 支持SMP(对称多处理器),但是如果每个处理器超过4或8个核(core)时,Mysql的扩展性表现较差.
13. 对于时间、日期、间隔等时间类型没有秒以下级别的存储类型.
14. 可用来编写存储过程、触发器、计划事件以及存储函数的语言功能较弱.
15. 没有基于回滚(roll-back)的恢复功能,只有前滚(roll-forward)的恢复功能.
16. 不支持快照功能.
17. 不支持数据库链(database link).有一种叫做Federated的存储引擎可以作为一个中转将查询语句传递到远程服务器的一个表上,不过,它功能很粗糙并且漏洞很多.
18. 数据完整性检查非常薄弱,即使是基本的完整性约束，也往往不能执行。
19. 优化查询语句执行计划的优化器提示非常少.
20. 只有一种表连接类型:嵌套循环连接(nested-loop),不支持排序-合并连接(sort-merge join)与散列连接(hash join).
21. 大部分查询只能使用表上的单一索引;在某些情况下,会存在使用多个索引的查询,但是查询优化器通常会低估其成本,它们常常比表扫描还要慢.
22. 不支持位图索引(bitmap index).每种存储引擎都支持不同类型的索引.大部分存储引擎都支持B-Tree索引.
23. 管理工具较少,功能也不够成熟.
24. 没有成熟能够令人满意的IDE工具与调试程序.可能不得不在文本编辑器中编写存储过程,并且通过往表(调试日志表)中插入记录的方式来做调试.
25. 每个表都可以使用一种不同的存储引擎.
26. 每个存储引擎在行为表现、特性以及功能上都可能有很大差异.
27. 大部分存储引擎都不支持外键.
28. 默认的存储引擎(MyISAM)不支持事务,并且很容易损坏.
29. 最先进最流行的存储引擎InnoDB由Oracle拥有.
30. 有些执行计划只支持特定的存储引擎.特定类型的Count查询,在这种存储引擎中执行很快,在另外一种存储引擎中可能会很慢.
31. 执行计划并不是全局共享的,,仅仅在连接内部是共享的.
32. 全文搜索功能有限, 只适用于非事务性存储引擎. Ditto用于地理信息系统/空间类型和查询.
33. 没有资源控制.一个完全未经授权的用户可以毫不费力地耗尽服务器的所有内存并使其崩溃,或者可以耗尽所有CPU资源.
34. 没有集成商业智能(business intelligence), OLAP **数据集等软件包.
35. 没有与Grid Control类似的工具( http://solutions.mysql.com/go.php?id=1296&t=s )
36. 没有类似于RAC的功能.如果你问”如何使用Mysql来构造RAC”,只能说你问错了问题.
37. 不支持用户自定义类型或域(domain).
38. 每个查询支持的连接的数量最大为61.
39. MySQL支持的SQL语法(ANSI SQL标准)的很小一部分.不支持递归查询、通用表表达式（Oracle的with 语句）或者窗口函数（分析函数）.支持部分类似于Merge或者类似特性的SQL语法扩展,不过相对于Oracle来讲功能非常简单.
40. 不支持功能列(基于计算或者表达式的列,Oracle11g 开始支持计算列,以及早期版本就支持虚列(rownum,rowid)).
41. 不支持函数索引,只能在创建基于具体列的索引.
42. 不支持物化视图.
43. 不同的存储引擎之间,统计信息差别很大,并且所有的存储引擎支持的统计信息都只支持简单的基数(cardinality)与一定范围内的记录数(rows-in-a-range). 换句话说，数据分布统计信息是有限的.更新统计信息的机制也不多.
44. 没有内置的负载均衡与故障切换机制.
45. 复制(Replication)功能是异步的,并且有很大的局限性.例如,它是单线程的(single-threaded),因此一个处理能力更强的Slave的恢复速度也很难跟上处理能力相对较慢的Master.
46. Cluster并不如想象的那么完美.或许我已经提过这一点,但是这一点值得再说一遍.
47. 数据字典(INFORMATION_SCHEMA)功能很有限,并且访问速度很慢(在繁忙的系统上还很容易发生崩溃).
48. 不支持在线的Alter Table操作.
49. 不支持Sequence.
50. 类似于ALTER TABLE或CREATE TABLE一类的操作都是非事务性的.它们会提交未提交的事务,并且不能回滚也不能做灾难恢复.Schame被保存在文件系统上,这一点与它使用的存储引擎无关.
PostgreSQL数据库可以解决以上问题中的：
1. 对子查询的优化表现不佳
2. 对复杂查询的处理较弱
3. 查询优化器不够成熟
PostgreSQL完全支持SQL-92标准，对SQL的支持也很全面，可以支持复杂的SQL查询。
4. 性能优化工具与度量信息不足
PostgreSQL提供了执行计划和详细的cost值，可以方便看到SQL的执行效率。
9. 存储过程与触发器的功能有限.
PostgreSQL提供了完善的存储过程和触发器支持。
11. 不支持MPP(大规模并行处理)
而PostgreSQL是类似Oracle数据库的架构，是多进程的架构，而不像MySQL是多线程的架构，所以能支持MPP。
18. 数据完整性检查非常薄弱,即使是基本的完整性约束，也往往不能执行。
PostgreSQL提供完善的数据完整性检查机制，支持外键。
20. 只有一种表连接类型:嵌套循环连接(nested-loop),不支持排序-合并连接(sort-merge join)与散列连接(hash join).
而PostgreSQL则支持这些表连接类型
21. 大部分查询只能使用表上的单一索引;在某些情况下,会存在使用多个索引的查询,但是查询优化器通常会低估其成本,它们常常比表扫描还要慢.
PostgreSQL数据不存在这个问题，假设表T的两个字段col1的col2上有两个索引,idx_1和idx_2，那么select * from t where col1=:a and col2=:b;查询时，PostgreSQL数据库有可能把这个查询转化为select * from t where col1=:a intersect select * from t where col2=:b，这样两个索引都可以使用上。
25. 每个表都可以使用一种不同的存储引擎.
26. 每个存储引擎在行为表现、特性以及功能上都可能有很大差异.
27. 大部分存储引擎都不支持外键.
28. 默认的存储引擎(MyISAM)不支持事务,并且很容易损坏.
29. 最先进最流行的存储引擎InnoDB由Oracle拥有.
30. 有些执行计划只支持特定的存储引擎.特定类型的Count查询,在这种存储引擎中执行很快,在另外一种存储引擎中可能会很慢.
PostgreSQL只有一种存储引擎，所以不存在上面的情况。而PostgreSQL支持完善的事务。
32. 全文搜索功能有限, 只适用于非事务性存储引擎. Ditto用于地理信息系统/空间类型和查询.
PostgreSQL数据库支持全文搜索，支持更多类型的索引，如B-tree,R-tree, Hash, GiST, GIN，R-tree,GIST,GIN索引可用于空间类型和查询。
37. 不支持用户自定义类型或域(domain).
PostgreSQL支持丰富的类型，同时也支持自定义类型。
39. MySQL支持的SQL语法(ANSI SQL标准)的很小一部分.不支持递归查询、通用表表达式（Oracle的with 语句）或者窗口函数（分析函数）.支持部分类似于Merge或者类似特性的SQL语法扩展,不过相对于Oracle来讲功能非常简单.
这些PostgreSQL数据库都支持，如窗口函数。
41. 不支持函数索引,只能在创建基于具体列的索引.
PostgreSQL支持函数索引
49. 不支持Sequence.
PostgreSQL支持sequence
50. 类似于ALTER TABLE或CREATE TABLE一类的操作都是非事务性的.它们会提交未提交的事务,并且不能回滚也不能做灾难恢复.Schame被保存在文
件系统上,这一点与它使用的存储引擎无关.
PostgreSQL不存在这个问题。
使用太广泛了，以至于我不得不将一些应用从mysql 迁移到postgresql, 很多开源软件都是以Mysql 作为数据库标准，并且以Mysql 作为抽象基础的，但是具体使用过程中，发现Mysql 有很多问题，所以都迁移到postgresql上了，转一个Mysql 和Postgresql 对比的文章：
性能测试：https://www.v2ex.com/t/418619
PostgreSQL 与 MySQL 相比，优势何在？
一、 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应用中很重要。
六、PG有极其强悍的 SQL 编程能力（9.x 图灵完备，支持递归！），有非常丰富的统计函数和统计语法支持，比如分析函数（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-query.log ，这个pg肯定可以定制出来，但是如果可以配置使用就更好了。
第二是mysql的innodb引擎，可以充分优化利用系统所有内存，超大内存下PG对内存使用的不那么充分，
第三点，MySQL的复制可以用多级从库，但是在9.2之前，PGSQL不能用从库带从库。
第四点，从测试结果上看，mysql 5.5的性能提升很大，单机性能强于pgsql，5.6应该会强更多.
第五点，对于web应用来说,mysql 5.6 的内置MC API功能很好用，PGSQL差一些。
另外一些：
pgsql和mysql都是背后有商业公司，而且都不是一个公司。大部分开发者，都是拿工资的。
说mysql的执行速度比pgsql快很多是不对的，速度接近，而且很多时候取决于你的配置。
对于存储过程，函数，视图之类的功能，现在两个数据库都可以支持了。
另外多线程架构和多进程架构之间没有绝对的好坏，oracle在unix上是多进程架构，在windows上是多线程架构。
很多pg应用也是24/7的应用，比如skype. 最近几个版本VACUUM基本不影响PGSQL 运行，8.0之后的PGSQL不需要cygwin就可以在windows上运行。
至于说对于事务的支持，mysql和pgsql都没有问题。
原文地址：http://www.zhihu.com/question/20010554
MySQLL和PostgreSQL的比较
PostgreSQL主要优势： PostgreSQL与oracle或InnoDB的多版本实现最大的区别在于最新版本和历史版本是否分离存储，PostgreSQL不分，而oracle和InnoDB分，而innodb也只是分离了数据,索引本身没有分开。 PostgreSQL的主要劣势在于： PostgreSQL异步提交（Asynchronous Commit）的功能： PostgreSQL中索引的特色功能： |
从特性角度，除了那些小型数据库之外，几乎所有数据库，都比MYSQL强。。但从现实角度讲，MYSQL又是最常用的
就像汽车。。。是奔驰好。还是面包车好。 从技术角度，怎么看都是奔驰好。。。但如果你是打算拉几袋水泥。。。却发现面包车就足够了。。
MYSQL其实可以算是面包车。。。论性能，论精度，跟专业大型数据库，完全没法比。。。但却很常见
PostgreSQL大概可以算是个皮卡。。比MYSQL强一些。。尤其使用起来，不像MYSQL有那么多坑。。但问题是，它出现的太晚了，市场已经全被MYSQL占了。。。所以，如果你是想自己做个项目，它肯定比MYSQL强。。。但如果你是打算找工作。。。还是学MYSQL吧。。否则我怕你找不到工作。。。。
ORACLE，DB2、还有SQL Server这三个，则可以看作奔驰，宝马，奥迪。。。它们强在哪。在于数据精确。。。所以如果你的项目可能用在金融，科研，军事等对数字精度敏感的行业，就需要使用这种级别的数据库。。。比如银行，一个小数点之后N位，随便出点差错，都可能导致上亿损失。。那数据库自然不可能使用MYSQL了。。。但对于一般的网络公司，MYSQL就够用了
MYSQL是个初中生里的垃圾学生。。。PostgreSQL是初中生里的三好学生。。。如果一件工作，需要大学生来做。。。MYSQL自然不行，但PostgreSQL也同样不行。。。。但如果一件工作，小学生就可以做。。。PostgreSQL能做，MYSQL也就同样可以。。。所以你说PostgreSQL是不是比MYSQL强。一定是强。。。但这并不足以改变什么
MySQL和Postgresql的区别
2017-12-17 22:01 by 晨曦曙光, 6378 阅读,
一.PostgreSQL相对于MySQL的优势
1、在SQL的标准实现上要比MySQL完善，而且功能实现比较严谨；
2、存储过程的功能支持要比MySQL好，具备本地缓存执行计划的能力；
3、对表连接支持较完整，优化器的功能较完整，支持的索引类型很多，复杂查询能力较强；
4、PG主表采用堆表存放，MySQL采用索引组织表，能够支持比MySQL更大的数据量。
5、PG的主备复制属于物理复制，相对于MySQL基于binlog的逻辑复制，数据的一致性更加可靠，复制性能更高，对主机性能的影响也更小。
6、MySQL的存储引擎插件化机制，存在锁机制复杂影响并发的问题，而PG不存在。
二、MySQL相对于PG的优势：
1、innodb的基于回滚段实现的MVCC机制，相对PG新老数据一起存放的基于XID的MVCC机制，是占优的。新老数据一起存放，需要定时触 发VACUUM，会带来多余的IO和数据库对象加锁开销，引起数据库整体的并发能力下降。而且VACUUM清理不及时，还可能会引发数据膨胀；
2、MySQL采用索引组织表，这种存储方式非常适合基于主键匹配的查询、删改操作，但是对表结构设计存在约束；
3、MySQL的优化器较简单，系统表、运算符、数据类型的实现都很精简，非常适合简单的查询操作；
4、MySQL分区表的实现要优于PG的基于继承表的分区实现，主要体现在分区个数达到上千上万后的处理性能差异较大。
5、MySQL的存储引擎插件化机制，使得它的应用场景更加广泛，比如除了innodb适合事务处理场景外，myisam适合静态数据的查询场景。
三、总体上来说，开源数据库都不是很完善，商业数据库oracle在架构和功能方面都还是完善很多的。从应用场景来说，PG更加适合严格的企业应用场景（比如金融、电信、ERP、CRM），而MySQL更加适合业务逻辑相对简单、数据可靠性要求较低的互联网场景（比如google、facebook、alibaba）。
MySQL与PostgreSQL的对比
MySQL的背后是一个成熟的商业公司，而PostgreSQL的背后是一个庞大的志愿开发组。这使得MySQL的开发过程更为慎重，而PostgreSQL的反应更为迅速。这样的两种背景直接导致了各自固有的优点和缺点。
PostgreSQL相对于MySQL的优势
1）不仅仅是关系型数据库
除了存储正常的数据类型外，还支持存储：
- array，不管是一位数组还是多为数组均支持
- json（hStore）和jsonb，相比使用text存储接送要高效很多
json和jsonb之间的区别
jsonb和json在更高的层面上看起来几乎是一样的，但在存储实现上是不同的。
- json存储完的文本，json列会每次都解析存储的值，它不支持索引，但你可以为查询创建表达式索引。
- jsonb存储的二进制格式，避免了重新解析数据结构。它支持索引，这意味着你可以不使用指定的索引就能查询任何路径。
当我们比较写入数据速度时，由于数据存储的方式的原因，jsonb会比json稍微的慢一点。json列会每次都解析存储的值，这意味着键的顺序要和输入的时候一样。但jsonb不同，以二进制格式存储且不保证键的顺序。因此，如果你有软件需要依赖键的顺序，jsonb可能不是你的应用的最佳选择。使用jsonb的优势还在于你可以轻易的整合关系型数据和非关系型数据， PostgreSQL对于mongodb这类的基于文档的数据库是个不小的威胁，毕竟如果一个表中只有一列数据的类型是半结构化的，没有必要为了迁就它而整个表的设计采用schemaless的结构。
2）支持地理信息处理扩展
PostGIS 为PostgreSQL提供了存储空间地理数据的支持，使PostgreSQL成为了一个空间数据库，能够进行空间数据管理、数量测量与几何拓扑分析。在功能上，和MYSQL对比，PostGIS具有下列优势：
O2O业务场景中的LBS业务使用PostgreSQL + PostGIS有无法比拟的优势。
3）可以快速构建REST API
PostgREST 可以方便的为任何 PostgreSQL 数据库提供完全的 RESTful API 服务。
4）支持树状结构
支持R-trees这样可扩展的索引类型，可以更方便地处理一些特殊数据。MySQL 处理树状的设计会很复杂, 而且需要写很多代码, 而 PostgreSQL 可以高效处理树结构。
5）有极其强悍的 SQL 编程能力
支持递归，有非常丰富的统计函数和统计语法支持。
- MySQL：支持 CREATE PROCEDURE 和 CREATE FUNCTION 语句。存储过程可以用 SQL 和 C++ 编写。用户定义函数可以用 SQL、C 和 C++ 编写。
- PostgreSQL：没有单独的存储过程，都是通过函数实现的。用户定义函数可以用 PL/pgSQL（专用的过程语言）、PL/Tcl、PL/Perl、PL/Python 、SQL 和 C 编写。
6）外部数据源支持
可以把 70 种外部数据源 (包括 Mysql, Oracle, CSV, hadoop …) 当成自己数据库中的表来查询。Postgres有一个针对这一难题的解决方案：一个名为“外部数据封装器（Foreign Data Wrapper，FDW）”的特性。该特性最初由PostgreSQL社区领袖Dave Page四年前根据SQL标准SQL/MED（SQL Management of External Data）开发。FDW提供了一个SQL接口，用于访问远程数据存储中的远程大数据对象，使DBA可以整合来自不相关数据源的数据，将它们存入Postgres数据库中的一个公共模型。这样，DBA就可以访问和操作其它系统管理的数据，就像在本地Postgres表中一样。例如，使用FDW for MongoDB，数据库管理员可以查询来自文档数据库的数据，并使用SQL将它与来自本地Postgres表的数据相关联。借助这种方法，用户可以将数据作为行、列或JSON文档进行查看、排序和分组。他们甚至可以直接从Postgres向源文档数据库写入（插入、更细或删除）数据，就像一个一体的无缝部署。也可以对Hadoop集群或MySQL部署做同样的事。FDW使Postgres可以充当企业的中央联合数据库或“Hub”。
7）没有字符串长度限制
一般关系型数据库的字符串有限定长度8k左右，无限长 TEXT 类型的功能受限，只能作为外部大数据访问。而PostgreSQL的 TEXT 类型可以直接访问，SQL语法内置正则表达式，可以索引，还可以全文检索，或使用xml xpath。MySQL 的各种text字段有不同的限制，要手动区分 small text, middle text, large text… PostgreSQL 没有这个限制，text 能支持各种大小。
8）支持图结构数据存储
没有具体使用过，具体可以自己搜索下。参考链接：https://mp.weixin.qq.com/s/cjor82wgDu5gzDvTYpLDWw
9）支持窗口函数
窗口函数提供跨行相关的当前查询行集执行计算的能力。仅当调用跟着OVER子句的聚集函数，作为窗口函数；否则它们作为常规的聚合函数。窗口也是一种分组，但和 group by 的分组不同。窗口，可以提供分组之外，还可以执行对每个窗口进行计算。可以相像成是group by 后，然后对每个分组进行计算，而不像Group by ，只是单纯地分组。MySQL 不支持 OVER 子句, 而PostgreSQL支持。OVER 子句能简单的解决 “每组取 top 5” 的这类问题。MySQL支持的SQL语法(ANSI SQL标准)的很小一部分。不支持递归查询、通用表表达式（Oracle的with 语句）或者窗口函数（分析函数）。
10）对索引的支持更强
PostgreSQL 的可以使用函数和条件索引，这使得PostgreSQL数据库的调优非常灵活，mysql就没有这个功能，条件索引在web应用中很重要。对于索引类型：
- MySQL：取决于存储引擎。MyISAM：BTREE，InnoDB：BTREE。
- PostgreSQL：支持 B-树、哈希、R-树和 Gist 索引。
InnoDB的表和索引都是按相同的方式存储。也就是说表都是索引组织表。这一般要求主键不能太长而且插入时的主键最好是按顺序递增，否则对性能有很大影响。PostgreSQL不存在这个问题。
索引类型方面，MySQL取决于存储引擎。MyISAM：BTREE，InnoDB：BTREE。PostgreSQL支持 B-树、哈希、R-树和 Gist 索引。
11）集群支持更好
Mysql Cluster可能与你的想象有较大差异。开源的cluster软件较少。复制(Replication)功能是异步的并且有很大的局限性。例如，它是单线程的(single-threaded)，因此一个处理能力更强的Slave的恢复速度也很难跟上处理能力相对较慢的Master。
PostgreSQL有丰富的开源cluster软件支持。plproxy 可以支持语句级的镜像或分片，slony 可以进行字段级的同步设置，standby 可以构建WAL文件级或流式的读写分离集群，同步频率和集群策略调整方便，操作非常简单。
另外，PostgreSQL的主备复制属于物理复制，相对于MySQL基于binlog的逻辑复制，数据的一致性更加可靠，复制性能更高，对主机性能的影响也更小。对于WEB应用来说，复制的特性很重要，mysql到现在也是异步复制，pgsql可以做到同步，异步，半同步复制。还有mysql的同步是基于binlog复制，类似oracle golden gate,是基于stream的复制，做到同步很困难，这种方式更加适合异地复制，pgsql的复制基于wal，可以做到同步复制。同时，pgsql还提供stream复制。
12）事务隔离做的更好
MySQL 的事务隔离级别 repeatable read 并不能阻止常见的并发更新, 得加锁才可以, 但悲观锁会影响性能, 手动实现乐观锁又复杂. 而 PostgreSQL 的列里有隐藏的乐观锁 version 字段, 默认的 repeatable read 级别就能保证并发更新的正确性, 并且又有乐观锁的性能。
13）对于字符支持更好一些
MySQL 里需要 utf8mb4 才能显示 emoji 的坑, PostgreSQL 没这个坑。
14）对表连接支持较完整
对表连接支持较完整，MySQL只有一种表连接类型:嵌套循环连接(nested-loop),不支持排序-合并连接(sort-merge join)与散列连接(hash join)。PostgreSQL都支持。
15）存储方式支持更大的数据量
PostgreSQL主表采用堆表存放，MySQL采用索引组织表，能够支持比MySQL更大的数据量。
16）时间精度更高
MySQL对于时间、日期、间隔等时间类型没有秒以下级别的存储类型，而PostgreSQL可以精确到秒以下。
17）优化器的功能较完整
MySQL对复杂查询的处理较弱，查询优化器不够成熟，explain看执行计划的结果简单。性能优化工具与度量信息不足。
PostgreSQL很强大的查询优化器，支持很复杂的查询处理。explain返回丰富的信息。提供了一些性能视图，可以方便的看到发生在一个表和索引上的select、delete、update、insert统计信息，也可以看到cache命中率。网上有一个开源的pgstatspack工具。
18)序列支持更好
MySQL 不支持多个表从同一个序列中取 id, 而 PostgreSQL 可以。
19）对子查询支持更好
对子查询的支持。虽然在很多情况下在SQL语句中使用子查询效率低下，而且绝大多数情况下可以使用带条件的多表连接来替代子查询，但是子查询的存在在很多时候仍然不可避免。而且使用子查询的SQL语句与使用带条件的多表连接相比具有更高的程序可读性。几乎任何数据库的子查询 (subquery) 性能都比 MySQL 好。
20）增加列更加简单
MySQL表增加列，基本上是重建表和索引，会花很长时间。PostgreSQL表增加列，只是在数据字典中增加表定义，不会重建表.
MySQL相对于PostgreSQL的优势
1）MySQL比PostgreSQL更流行
流行对于一个商业软件来说，也是一个很重要的指标，流行意味着更多的用户，意味着经受了更多的考验，意味着更好的商业支持、意味着更多、更完善的文档资料。易用，很容易安装。第三方工具，包括可视化工具，让用户能够很容易入门。
2）回滚实现更优
innodb的基于回滚段实现的MVCC机制，相对PG新老数据一起存放的基于XID的MVCC机制，是占优的。新老数据一起存放，需要定时触发VACUUM，会带来多余的IO和数据库对象加锁开销，引起数据库整体的并发能力下降。而且VACUUM清理不及时，还可能会引发数据膨胀。
3）在Windows上运行更可靠
与PostgreSQL相比，MySQL更适宜在Windows环境下运行。MySQL作为一个本地的Windows应用程序运行(在 NT/Win2000/WinXP下，是一个服务)，而PostgreSQL是运行在Cygwin模拟环境下。PostgreSQL在Windows下运行没有MySQL稳定，应该是可以想象的。
4）线程模式相比进程模式的优势
MySQL使用了线程，而PostgreSQL使用的是进程。在不同线程之间的环境转换和访问公用的存储区域显然要比在不同的进程之间要快得多。
- 进程模式对多CPU利用率比较高。进程模式共享数据需要用到共享内存，而线程模式数据本身就是在进程空间内都是共享的，不同线程访问只需要控制好线程之间的同步。
- 线程模式对资源消耗比较少。所以MySQL能支持远比PostgreSQL多的更多的连接。但PostgreSQL中有优秀的连接池软件软件，如pgbouncer和pgpool，所以通过连接池也可以支持很多的连接。
5）权限设置上更加完善
MySQL在权限系统上比PostgreSQL某些方面更为完善。PostgreSQL只支持对于每一个用户在一个数据库上或一个数据表上的 INSERT、SELECT和UPDATE/DELETE的授权，而MySQL允许你定义一整套的不同的数据级、表级和列级的权限。对于列级的权限， PostgreSQL可以通过建立视图，并确定视图的权限来弥补。MySQL还允许你指定基于主机的权限，这对于目前的PostgreSQL是无法实现的，但是在很多时候，这是有用的。
6）存储引擎插件化机制
MySQL的存储引擎插件化机制，使得它的应用场景更加广泛，比如除了innodb适合事务处理场景外，myisam适合静态数据的查询场景。
7）适应24/7运行
MySQL可以适应24/7运行。在绝大多数情况下，你不需要为MySQL运行任何清除程序。PostgreSQL目前仍不完全适应24/7运行，这是因为你必须每隔一段时间运行一次VACUUM。
8）更加试用于简单的场景
PostgreSQL只支持堆表，不支持索引组织表，Innodb只支持索引组织表。
- 索引组织表的优势：表内的数据就是按索引的方式组织，数据是有序的，如果数据都是按主键来访问，那么访问数据比较快。而堆表，按主键访问数据时，是需要先按主键索引找到数据的物理位置。
- 索引组织表的劣势：索引组织表中上再加其它的索引时，其它的索引记录的数据位置不再是物理位置，而是主键值，所以对于索引组织表来说，主键的值不能太大，否则占用的空间比较大。
- 对于索引组织表来说，如果每次在中间插入数据，可能会导致索引分裂，索引分裂会大大降低插入的性能。所以对于使用innodb来说，我们一般最好让主键是一个无意义的序列，这样插入每次都发生在最后，以避免这个问题。
由于索引组织表是按一个索引树，一般它访问数据块必须按数据块之间的关系进行访问，而不是按物理块的访问数据的，所以当做全表扫描时要比堆表慢很多，这可能在OLTP中不明显，但在数据仓库的应用中可能是一个问题。
总结
MySQL从一开始就没有打算做所有事情，因而它在功能方面有一定的局限性，并不能满足一些先进应用程序的要求。MySQL对某些功能（例如引用、事务、审计等）的实现方式使得它与其他的关系型数据库相比缺少了一些可靠性。对于简单繁重的读取操作，使用PostgreSQL可能有点小题大做，同时性能也比MySQL这样的同类产品要差。除非你需要绝对的数据完整性，ACID遵从性或者设计复杂，否则PostgreSQL对于简单的场景而言有点多余。
如何你确定只在MySQL和PostgreSQL中进行选择，以下规则总是有效的：
- 如果你的操作系统是Windows，你应该使用MySQL。
- 当绝对需要可靠性和数据完整性的时候，PostgreSQL是更好的选择。
- 如果需要数据库执行定制程序，那么可扩展的PostgreSQL是更好的选择。
- 你的应用处理的是地理数据，由于R-TREES的存在，你应该使用PostgreSQL。
- 如果你对数据库并不了十分了解，甚至不知道事务、存储过程等究竟是什么，你应该使用MySQL。
为什么选择PostgreSQL而不是MySQL
| 2015-03-27 11:51
David Bolton是一名独立开发者，他使用PostgreSQL和MySQL都已有超过十年的时间。近日，他撰文阐述了选择PostgreSQL而不是MySQL的理由。他认为，MySQL之所以仍然如此流行是因为每个Linux Web托管软件包中都包含它。但随着Oracle将其收购，MySQL的开源程度大不如前。而PostgreSQL不仅发展更快，还加入了JSON支持，成为少数几个支持NoSQL的关系型数据库之一。
MySQL/MariaDB的当前版本是5.7.6（MariaDB为MySQL创建者Monty Widenius创建的一个MySQL分支），PostgreSQL的版本是9.4.1。Bolton从以下几个方面对比了两者的最新版本：
- ANSI标准兼容性：与先前的版本相比，MySQL已经有了长足的进步，但MySQL背后的哲学是，如果客户喜欢，他们就会支持非标准扩展，而PostgreSQL从开始就将标准构建到平台里。不过，二者殊途同归，差别不大；
- ACID遵从性：PostgreSQL有一个存储引擎，而MySQL有9个，但只有MyIsam和InnoDB与大部分用户有关，其中，后者为默认存储引擎。InnoDB和PostgreSQL都完全遵循ACID，差别不大；
- 无锁表修改：MyIsam使用表级锁来提升速度，这会导致写互斥。但PostgreSQL和InnoDB均使用行级锁，差别不大；
- 子查询：长期以来，这一直是MySQL的一个弱点，虽然5.6.5作了重大改进，但PostgreSQL对表连接支持得更好，尤其是MySQL不支持全外连接，因此，这方面PostgreSQL胜过MySQL；
- JSON支持和NoSQL：PostgreSQL最近增加了JSON支持，与传统的关系型数据库相比，它提供了更大的数据存储灵活性，因此，这方面PostgreSQL胜过MySQL。
此外，Bolton指出，选择PostgreSQL还有如下理由：
- 更好的许可：PostgreSQL采用类似MIT的许可协议，允许开发人员做任何事情，包括在开源或闭源产品中商用，而MySQL的客户端遵循GPL许可协议，所以开发人员必须向Oracle付费或者将自己的应用程序开源；
- 更好的数据一致性： PostgreSQL会在数据插入和更新之前进行严格的验证，确保数据合法才会进行相应的操作，但在MySQL中，开发人员需要将服务器设定为严格SQL模式才能达到同样的目的，否则可能会产生不规范数据；
- 服务器扩展：MySQL提供了插件程序API，支持C/C++或任何兼容C的语言，而且从5.7.3版本开始支持全文搜索，PostgreSQL有一个类似的系统但支持的语言更多，包括C/C++、Java、.Net、Perl、 Python、Ruby、Tcl、ODBC等，它甚至可以在单独的进程中运行用户提供的代码；除了所有关系型数据库都包含的有关数据库、表和列的一般信息外，PostgreSQL系统目录中还可以包含关于数据类型、函数和存取方法的信息，开发人员可以通过修改这些信息实现扩展。
“王者对战”之 MySQL 8 vs PostgreSQL 10
既然 MySQL 8 和 PostgreSQL 10 已经发布了，现在是时候回顾一下这两大开源关系型数据库是如何彼此竞争的。
在这些版本之前，人们普遍认为，Postgres 在功能集表现更出色，也因其“学院派”风格而备受称赞，MySQL 则更善长大规模并发读/写。
但是随着它们最新版本的发布，两者之间的差距明显变小了。
特性比较
让我们来看看我们都喜欢谈论的“时髦”功能。
| 特性 | MySQL 8 | PostgreSQL 10 |
|---|---|---|
| 查询 & 分析 | ||
| 公用表表达式 (CTEs) | ✔ New | ✔ |
| 窗口函数 | ✔ New | ✔ |
| 数据类型 | ||
| JSON 支持 | ✔ Improved | ✔ |
| GIS / SRS | ✔ Improved | ✔ |
| 全文检索 | ✔ | ✔ |
| 可扩展性 | ||
| 逻辑复制 | ✔ | ✔ New |
| 半同步复制 | ✔ | ✔ New |
| 声明式分区 | ✔ | ✔ New |
过去经常会说 MySQL 最适合在线事务，PostgreSQL 最适合分析流程。但现在不是了。
公共表表达式(CTEs) 和窗口函数是选择 PostgreSQL 的主要原因。但是现在，通过引用同一个表中的 boss_id 来递归地遍历一张雇员表，或者在一个排序的结果中找到一个中值（或 50%），这在 MySQL 上不再是问题。
在 PostgreSQL 中进行复制缺乏配置灵活性，这就是 Uber 转向 MySQL 的原因。但是现在，有了逻辑复制特性，就可以通过创建一个新版本的 Postgres 并切换到它来实现零停机升级。在一个巨大的时间序列事件表中截断一个陈旧的分区也要容易得多。
就特性而言，这两个数据库现在都是一致的。
有哪些不同之处呢？
现在，我们只剩下一个问题 —— 那么，选择一个而不选另一个的原因是什么呢？
生态系统是其中一个因素。MySQL 有一个充满活力的生态系统，包括 MariaDB、Percona、Galera 等等，以及除 InnoDB 以外的存储引擎，但这也可能是和令人困惑的。Postgres 的高端选择有限，但随着最新版本引入的新功能，这会有所改变。
治理是另一个因素。当 Oracle（或最初的 SUN）收购 MySQL时，每个人都担心他们会毁掉这个产品，但在过去的十年里，这并不是事实。事实上，在收购之后，发展反倒加速了。而 Postgres 在工作管理和协作社区方面有着丰富的经验。
基础架构不会经常改变，虽然近来没有对这方面的详细讨论，这也是值得再次考虑的。
来复习下：
| 特性 | MySQL 8 | PostgreSQL 10 |
|---|---|---|
| 架构 | 单进程 | 多进程 |
| 并发 | 多线程 | fork(2) |
| 表结构 | 聚簇索引 | 堆 |
| 页压缩 | Transparent | TOAST |
| 更新 | In-Place / Rollback Segments | Append Only / HOT |
| 垃圾回收 | 清除线程 | 自动清空进程 |
| 事务日志 | REDO Log (WAL) | WAL |
| 复制日志 | Separate (Binlog) | WAL |
进程vs线程
当 Postgres 派生出一个子进程来建立连接时，每个连接最多可以占用 10MB。与 MySQL 的线程连接模型相比，它的内存压力更大，在 64 位平台上，线程的默认堆栈大小为 256KB。（当然，线程本地排序缓冲区等使这种开销变得不那么重要，即使在不可以忽略的情况下，仍然如此。）
尽管“写时复制”保存了一些与父进程共享的、不可变的内存状态，但是当您有 1000 多个并发连接时，基于流程的架构的基本开销是很繁重的，而且它可能是容量规划的最重要的因素之一。
也就是说，如果你在 30 台服务器上运行一个 Rails 应用，每个服务器都有 16 个 CPU 核心 32 线程，那么你有 960 个连接。可能只有不到 0.1% 的应用会超出这个范围，但这是需要记住的。
聚簇索引 vs 堆表
聚簇索引是一种表结构，其中的行直接嵌入其主键的 b 树结构中。一个（非聚集）堆是一个常规的表结构，它与索引分别填充数据行。
有了聚簇索引，当您通过主键查找记录时，单次 I/O 就可以检索到整行，而非集群则总是需要查找引用，至少需要两次 I/O。由于外键引用和 JOIN 将触发主键查找，所以影响可能非常大，这将导致大量查询。
聚簇索引的一个理论上的缺点是，当您使用二级索引进行查询时，它需要遍历两倍的树节点，第一次扫描二级索引，然后遍历聚集索引，这也是一棵树。
但是，如果按照现代表设计的约定，将一个自动增量整数作为主键[1]——它被称为代理键——那么拥有一个聚集索引几乎总是可取的。更重要的是，如果您做了大量的 ORDER BY id 来检索最近的（或最老的）N 个记录的操作，我认为这是很适用的。
Postgres 不支持聚集索引，而 MySQL(InnoDB)不支持堆。但不管怎样，如果你有大量的内存，差别应该是很小的。
页结构和压缩
Postgres 和 MySQL 都有基于页面的物理存储。(8KB vs 16KB)
页结构看起来就像右边的图。它包含一些我们不打算在这里讨论的条目，但是它们包含关于页的元数据。条目后面的项是一个数组标识符，由指向元组或数据行的（偏移、长度）对组成。在 Postgres 中，相同记录的多个版本可以以这种方式存储在同一页面中。
MySQL 的表空间结构与 Oracle 相似，它有多个层次，包括层、区段、页面和行层。
此外，它还有一个用于撤销的单独段，称为“回滚段”。与 Postgres 不同的是，MySQL 将在一个单独的区域中保存同一记录的多个版本。
如果存在一行必须适合两个数据库的单个页面，，这意味着一行必须小于 8KB。（至少有 2 行必须适合 MySQL 的页面，恰巧是 16KB/2 = 8KB）
那么当你在一个列中有一个大型 JSON 对象时会发生什么呢？
Postgres 使用 TOAST，这是一个专用的影子表(shadow table)存储。当行和列被选中时，大型对象就会被拉出。换句话说，大量的黑盒不会污染你宝贵的缓存。它还支持对 TOAST 对象的压缩。
MySQL 有一个更复杂的特性，叫做透明页压缩，这要归功于高端 SSD 存储供应商 Fusio-io 的贡献。它设计目的是为了更好地使用 SSD，在 SSD 中，写入量与设备的寿命直接相关。
对 MySQL 的压缩不仅适用于页面外的大型对象，而且适用于所有页面。它通过在稀疏文件中使用打孔来实现这一点，这是被 ext4 或 btrfs 等现代文件系统支持的。
有关更多细节，请参见：在 FusionIO 上使用新 MariaDB 页压缩获得显著的性能提升。
更新的开销
另一个经常被忽略的特性，但是对性能有很大的影响，并且可能是最具争议的话题，是更新。
这也是Uber放弃Postgres的另一个原因，这激起了许多Postgres的支持者来反驳它。
-
MySQL 对Uber可能是合适的, 但是未必对你合适
两者都是MVCC数据库，它们可以隔离多个版本的数据。
为了做到这一点，Postgres将旧数据保存在堆中，直到被清空，而MySQL将旧数据移动到一个名为回滚段的单独区域。
在Postgres中，当您尝试更新时，整个行必须被复制，以及指向它的索引条目也被复制。这在一定程度上是因为Postgres不支持聚集索引，所以从索引中引用的一行的物理位置不是由逻辑键抽象出来的。
为了解决这个问题，Postgres使用了堆上元组（HOT），在可能的情况下不更新索引。但是，如果更新足够频繁（或者如果一个元组比较大），元组的历史可以很容易地超过8 KB的页面大小，跨越多个页面并限制该特性的有效性。修剪和/或碎片整理的时间取决于启发式解决方案。另外，设置不超过100的填充参数会降低空间效率——这是一种很难在创建表时考虑的折衷方案。
这种限制更深入; 因为索引元组没有关于事务的任何信息，所以直到9.2之前一直不能支持仅索引扫描。 它是所有主要数据库（包括MySQL，Oracle，IBM DB2和Microsoft SQL Server）支持的最古老，最重要的优化方法之一。 但即使使用最新版本，当有许多UPDATE在可见性映射中设置脏位时，Postgres也不能完全支持仅索引扫描，并且在我们不需要时经常选择Seq扫描。
在MySQL上，更新发生在原地，旧的行数据被封存在一个称为回滚段的独立区域中。 结果是你不需要VACUUM，并且提交非常快，而回滚相对较慢，这对于大多数用例来说是一个可取的折衷。
它也足够聪明，尽快清除历史。 如果事务的隔离级别设置为READ-COMMITTED或更低，则在语句完成时清除历史记录。
事务记录的大小不会影响主页面。 碎片化是一个伪命题。 因此，在MySQL上能更好，更可预测整体性能。
Garbage Collection 垃圾回收
在Postgres中VACUUM上开销很高，因为它在主要工作在堆区，造成了直接的资源竞争。它感觉就像是编程语言中的垃圾回收 - 它会挡在路上，并随时让你停下来。
为具有数十亿记录的表配置autovacuum仍然是一项挑战。
在MySQL上清除（Purge）也可能相当繁重，但由于它是在单独的回滚段中使用专用线程运行的，因此它不会以任何方式影响读取的并发性。即使使用默认配置，变膨胀的回滚段使你执行速度减慢的可能性也是很低的。
拥有数十亿记录的繁忙表不会导致MySQL上的历史数据膨胀，诸如存储上的文件大小和查询性能等事情上几乎是可以预测的并且很稳定。
日志与副本
Postgres 拥有被称作 预写日志 (WAL)的单信源事务历史。它一直被用于副本，并且称为逻辑复制的新功能可将二进制内容快速解码为更易消化的逻辑语句，从而可对数据进行细粒度控制。
MySQL维护两个单独的日志：1.用于崩溃恢复的InnoDB特定的重做日志，以及 2. 用于复制和增量备份的二进制日志。
InnoDB 上的重做日志与 Oracle 一致，它是一个免维护的循环缓冲区，不会随着时间的推移而增长，只在启动时以固定大小创建。 这种设计保证在物理设备上保留一个连续的连续区域，从而提高性能。 更大的重做日志产生更高的性能，但要以崩溃恢复时间为代价。
随着新的复制功能添加到Postgres，我觉得他们不分伯仲。
前面文章太长不想读的话，请看后面的总结
令人惊讶的是，它证明了普遍的观点依然存在；MySQL最适合在线交易，而PostgreSQL最适合仅用于append only模式，像数据仓库一样分析过程。[2]
正如我们在这篇文章中看到的，Postgres的绝大多数难题都来自于append only模式，过于冗余的堆结构。
Postgres的未来版本可能需要对其存储引擎进行重大改进。您不必为接受我说的——实际上在官方wiki上已经有对它的讨论，这表明现在是时候从InnoDB身上学回来一些好的想法了。
人们一次又一次的说MySQL正在追赶Postgres，但是这一次，潮流已经改变。
——————————————————————————————————————————
-
UUID作为主键是一个可怕的想法，顺便说一句——密码随机性完全是为了杀死引用的局部性而设计，因此性能会损失。↩︎
-
当我说Postgres特别适合分析时，我是认真的：万一你不知道TimescaleDB，它是PostgreSQL上边的一个封装，允许你每秒插入100万条数据，每台服务器又1000亿行。多么疯狂的事情。难怪Amazon会选择PostgreSQL作为Redshift的基础。
PostgreSQL与MySQL对比
都属于开放源码的一员，性能和功能都在高速地提高和增强。MySQL AB的人们和PostgreSQL的开发者们都在尽可能地把各自的数据库改得越来越好，所以对于任何商业数据库使用其中的任何一个都不能算是错误的选择。
PostgreSQL : 免费
原则: 对于一个数据库，稳定性和速度并不能代表一切。对于一个成熟的数据库，稳定性肯定会日益提供。而随着硬件性能的飞速提高，速度也不再是什么太大的问题。
1 架构对比
MySQL： 多线程
PostgreSQL： 多进程
多线程架构和多进程架构之间没有绝对的好坏，例如oracle在unix上是多进程架构，在windows上是多线程架构。
PG 的有多种集群架构可以选择，plproxy 可以支持语句级的镜像或分片，slony 可以进行字段级的同步设置，standby 可以构建WAL文件级或流式的读写分离集群，同步频率和集群策略调整方便，操作非常简单。
pgsql对于numa架构的支持比mysql强一些，比MYSQL对于读的性能更好一些，pgsql提交可以完全异步，而mysql的内存表不够实用（因为表锁的原因）
2 对存储过程[1]及事务的支持能力
1） MySQL对于无事务的MyISAM表，采用表锁定，一个长时间运行的查询很可能会长时间地阻碍对表的更新，而PostgreSQL不存在这样的问题。
2） PostgreSQL支持存储过程，要比MySQL好，具备本地缓存执行计划的能力；
3） MySQL 4.0.2-alpha开始支持事务的概念，保留无事务的表类型， 为用户提供了更多的选择。
3 稳定性及性能
1）高并发读写，负载逼近极限下，PG的性能指标仍可以维持双曲线甚至对数曲线，到顶峰之后不再下降，而 MySQL 明显出现一个波峰后下滑（5.5版本之后，在企业级版本中有个插件可以改善很多，不过需要付费）
2） PostgreSQL 的稳定性极强， Innodb 等引擎在崩溃、断电之类的灾难场景下抗打击能力有了长足进步，然而很多 MySQL 用户都遇到过Server级的数据库丢失的场景——mysql系统库是MyISAM的，相比之下，PG数据库这方面要好一些。
3） mysql的innodb引擎，可以充分优化利用系统所有内存，超大内存下PG对内存使用的不那么充分（需要根据内存情况合理配置）。从测试结果上看，mysql 5.5的性能提升很大，单机性能强于pgsql，5.6应该会强更多。
4 高可用性
MySQL可以适应24/7运行。在绝大多数情况下，你不需要为MySQL运行任何清除程序。PostgreSQL目前仍不完全适应24/7运行，这是因为你必须每隔一段时间运行一次VACUUM。
innodb的基于回滚段实现的MVCC机制，相对PG新老数据一起存放的基于XID的MVCC机制，是占优的。新老数据一起存放，需要定时触 发VACUUM，会带来多余的IO和数据库对象加锁开销，引起数据库整体的并发能力下降。而且VACUUM清理不及时，还可能会引发数据膨胀；
5 数据同步方式：
1）mysql到现在也是异步复制，pgsql可以做到同步，异步，半同步复制。
2） mysql的同步是基于binlog复制，类似oracle golden gate,是基于stream的复制，做到同步很困难，这种方式更加适合异地复制；pgsql的复制基于wal，可以做到同步复制。同时，pgsql还提供stream复制。
3） MySQL的复制可以用多级从库，但是在9.2之前，PGSQL不能用从库带从库。
4） PG的主备复制属于物理复制，相对于MySQL基于binlog的逻辑复制，数据的一致性更加可靠，复制性能更高，对主机性能的影响也更小。
7 权限控制对比
MySQL允许你定义一整套的不同的数据级、表级和列级的权限，允许你指定基于主机的权限；
MySQL的MERGE表提供了一个独特管理多个表的方法。myisampack可以对只读表进行压缩，此后仍然可以直接访问该表中的行。
7 SQL语句支持能力
1） PG有极其强悍的 SQL 编程能力（9.x 图灵完备，支持递归！），有非常丰富的统计函数和统计语法支持，比如分析函数（ORACLE的叫法，PG里叫window函数）；
2） 支持用多种语言来写存储过程，对于R的支持也很好。这一点上MYSQL就差的很远，很多分析功能都不支持。腾讯内部数据存储主要是MYSQL，但是数据分析主要是HADOOP+PGSQL（听李元佳说过，但是没有验证过）。
3） pgsql对表名大小的处理，只有在SQL语句中，表名加双引号，才区分大小写。
4）在SQL的标准实现上要比MySQL完善，而且功能实现比较严谨；
5）对表连接支持较完整，优化器的功能较完整，支持的索引类型很多，复杂查询能力较强；
6） MySQL采用索引组织表，这种存储方式非常适合基于主键匹配的查询、删改操作，但是对表结构设计存在约束；
7） MySQL的Join操作的性能非常的差，只支持Nest Join，所以一旦数据量大，性能就非常的差。PostgreSQL除了支持nest join外，还支持hash join和 sort merge join；PostgreSQL支持正则表达式查找，MySQL不支持；
8 数据类型支持能力
PostgreSQL可以更方便地使用UDF(用户定义函数)进行扩展。
1) 有丰富的几何类型，实际上不止几何类型，PG有大量字典、数组、bitmap 等数据类型, 因此PG 多年来在 GIS 领域处于优势地位。相比之下mysql就差很多，instagram就是因为PG的空间数据库扩展POSTGIS远远强于MYSQL的my spatial而采用PGSQL的。MYSQL中的空间数据类型有4种，分别是GEOMETRY、POINT、LINESTRING、POLYGON，其空间索引只能在存储引擎为MYISAM的表中创建，用SPATIAL关键字进行扩展，使得能够用于创建正规索引类型的语法创建空间索引。创建空间索引的列，必须将其声明为NOT NULL。不同的存储引擎有差别。MyISAM和InnoDB都支持spatial extensions，但差别在于：如果使用MyISAM，可以建立spatial index，而InnoDB是不支持的。
2） pgsql对json支持比较好，还有很逆天的fdw[2]功能，就是把别的数据库的表当自己的用；
3） pgsql的字段类型支持的多，有很多mysql没有的类型，但是实际中有时候用到。
4） 一般关系型数据库的字符串有限定长度8k左右，无限长 TEXT 类型的功能受限，只能作为外部大数据访问。而 PG 的 TEXT 类型可以直接访问，SQL语法内置正则表达式，可以索引，还可以全文检索，或使用xml xpath。用PG的话，文档数据库都可以省了。
5） postgresql有grouping sets函数，也是迫使我抛弃mysql第一原因。做报表后台计算，olap/oltp之类的这个函数简直是刚性需求。没有grouping sets函数，我感觉做报表后台计算，简直惨不忍睹。当然pgsql还有挺多很好用的窗口函数之类，用起来真心爽。mysql做数据报表计算后台最大缺点就是没有grouping sets和一些窗口函数，替代方案很麻烦而且效率低，做很多统计数据各种表连接、外连接等等一大堆，不同数据库之间数据的利用计算。
8） PG支持R-trees这样可扩展的索引类型，可以更方便地处理一些特殊数据。
9）PG可以使用函数和条件索引，使得数据库的调优非常灵活，mysql就没有这个功能，条件索引在web应用中很重要。
9 入库过程容错能力
大批量数据入库，PostgresSQL要求所有数据必须完全满足要求，有一条错误，整个数据入库过程失败；MySQL无此问题。比如，每天1000万行数据，就因为一条打印的不完整，PostgreSQL会直接报错，导致一条也导入不进去。1000万里面有一行将数字类型的等级打印成了字符串的东西，那么pgsql会非让你找出这一条删掉，然后才能将剩下的数据导入进去。mysql就完全没有这个问题，比如mysql level字段定义的int类型，几千万中有一条数据没注意打印成字符串，mysql会自己给你转成0存储的，不会有任何报错。
10 表组织方式
1） pgsql用继承的方法实现分区表，让分区表的使用不方便且性能差，这点比不上mysql。
2） PG主表采用堆表存放，MySQL采用索引组织表，能够支持比MySQL更大的数据量；
3） MySQL分区表的实现要优于PG的基于继承表的分区实现，主要体现在分区个数达到上千上万后的处理性能差异较大。
11 开发接口
对于web应用来说,mysql 5.6 的内置MC API功能很好用，PGSQL差一些。
PG 的“无锁定”特性非常突出，甚至包括 vacuum 这样的整理数据空间的操作，这个和PGSQL的MVCC实现有关系。
12 维护团队
MySQL的背后是一个成熟的商业公司，使得MySQL的开发过程更为慎重；
PostgreSQL的背后是一个庞大的志愿开发组， PostgreSQL的反应更为迅速。这样的两种背景直接导致了各自固有的优点和缺点。
PostgreSQL 的名字很少听到，最近试装发现不是很友好；官方文档写的对新手来说有点坑；
有数据库工作经验的直接看最后一句就可以。
如果打算为项目选择一款免费、开源的数据库，那么你可能会在MySQL与PostgreSQL之间犹豫不定。MySQL与PostgreSQL都是免费、开源、强大、且功能丰富的数据库。你主要的问题可能是：哪一个才是最好的开源数据库，MySQL还是PostgreSQL呢？该选择哪一个开源数据库呢？
在选择数据库时，你所做的是个长期的决策，因为后面如果再改变决定将是非常困难且代价高昂的。你希望一开始就选择正确。两个流行的开源数据库MySQL与PostgreSQL常常成为最后要选择的产品。对这两个开源数据库的高层次概览将会有助于你选择最适合自己需要的。
MySQL
MySQL相对来说比较年轻，首度出现在1994年。它声称自己是最流行的开源数据库。MySQL就是LAMP（用于Web开发的软件包，包括 Linux、Apache及Perl/PHP/Python）中的M。构建在LAMP栈之上的大多数应用都会使用MySQL，包括那些知名的应用，如 WordPress、Drupal、Zend及phpBB等。
一开始，MySQL的设计目标是成为一个快速的Web服务器后端，使用快速的索引序列访问方法（ISAM），不支持ACID。经过早期快速的发展之 后，MySQL开始支持更多的存储引擎，并通过InnoDB引擎实现了ACID。MySQL还支持其他存储引擎，提供了临时表的功能（使用MEMORY存 储引擎），通过MyISAM引擎实现了高速读的数据库，此外还有其他的核心存储引擎与第三方引擎。
MySQL的文档非常丰富，有很多质量不错的免费参考手册、图书与在线文档，还有来自于Oracle和第三方厂商的培训与支持。
MySQL近几年经历了所有权的变更和一些颇具戏剧性的事件。它最初是由MySQL AB开发的，然后在2008年以10亿美金的价格卖给了Sun公司，Sun公司又在2010年被Oracle收购。Oracle支持MySQL的多个版 本：Standard、Enterprise、Classic、Cluster、Embedded与Community。其中有一些是免费下载的，另外一 些则是收费的。其核心代码基于GPL许可，对于那些不想使用GPL许可的开发者与厂商来说还有商业许可可供使用。
现在，基于最初的MySQL代码还有更多的数据库可供选择，因为几个核心的MySQL开发者已经发布了MySQL分支。最初的MySQL创建者之一 Michael "Monty" Widenius貌似后悔将MySQL卖给了Sun公司，于是又开发了他自己的MySQL分支MariaDB，它是免费的，基于GPL许可。知名的 MySQL开发者Brian Aker所创建的分支Drizzle对其进行了大量的改写，特别针对多CPU、云、网络应用与高并发进行了优化。
PostgreSQL
PostgreSQL标榜自己是世界上最先进的开源数据库。PostgreSQL的一些粉丝说它能与Oracle相媲美，而且没有那么昂贵的价格和傲慢的客服。它拥有很长的历史，最初是1985年在加利福尼亚大学伯克利分校开发的，作为Ingres数据库的后继。
PostgreSQL是完全由社区驱动的开源项目，由全世界超过1000名贡献者所维护。它提供了单个完整功能的版本，而不像MySQL那样提供了 多个不同的社区版、商业版与企业版。PostgreSQL基于自由的BSD/MIT许可，组织可以使用、复制、修改和重新分发代码，只需要提供一个版权声 明即可。
可靠性是PostgreSQL的最高优先级。它以坚如磐石的品质和良好的工程化而闻名，支持高事务、任务关键型应用。PostgreSQL的文档非 常精良，提供了大量免费的在线手册，还针对旧版本提供了归档的参考手册。PostgreSQL的社区支持是非常棒的，还有来自于独立厂商的商业支持。
数据一致性与完整性也是PostgreSQL的高优先级特性。PostgreSQL是完全支持ACID特性的，它对于数据库访问提供了强大的安全性 保证，充分利用了企业安全工具，如Kerberos与OpenSSL等。你可以定义自己的检查，根据自己的业务规则确保数据质量。在众多的管理特性 中，point-in-time recovery（PITR）是非常棒的特性，这是个灵活的高可用特性，提供了诸如针对失败恢复创建热备份以及快照与恢复的能力。但这并不是 PostgreSQL的全部，项目还提供了几个方法来管理PostgreSQL以实现高可用、负载均衡与复制等，这样你就可以使用适合自己特定需求的功能 了。
平台
MySQL与PostgreSQL都出现在一些高流量的Web站点上：
MySQL：Slashdot、Twitter、Facebook与Wikipedia
PostgreSQL：Yahoo使用了一个修改的PostgreSQL数据库来处理每天数以亿计的事件，还有Reddit和Disqus
MySQL与PostgreSQL都能运行在多个操作系统上，如Linux、Unix、Mac OS X与Windows。他们都是开源、免费的，因此测试他们时的唯一代价就是你的时间与硬件。他们都很灵活且具有可伸缩性，可用在小型系统和大型分布式系统 上。MySQL在一个领域上要比PostgreSQL更进一步，那就是它的触角延伸到了嵌入式领域，这是通过libmysqld实现的。 PostgreSQL不支持嵌入式应用，依然坚守在传统的客户端/服务器架构上。
MySQL通常被认为是针对网站与应用的快速数据库后端，能够进行快速的读取和大量的查询操作，不过在复杂特性与数据完整性检查方面不太尽如人意。 PostgreSQL是针对事务型企业应用的严肃、功能完善的数据库，支持强ACID特性和很多数据完整性检查。他们二者都在某些任务上具有很快的速 度，MySQL不同存储引擎的行为有较大差别。MyISAM引擎是最快的，因为它只执行很少的数据完整性检查，适合于后端读操作较多的站点，不过对于包含 敏感数据的读/写数据库来说就是个灾难了，因为MyISAM表最终可能会损坏。MySQL提供了修复MySQL表的工具，不过对于敏感数据来说，支持 ACID特性的InnoDB则是个更好的选择。
与之相反，PostgreSQL则是个只有单一存储引擎的完全集成的数据库。你可以通过调整postgresql.conf文件的参数来改进性能，也可以调整查询与事务。PostgreSQL文档对于性能调优提供了非常详尽的介绍。
MySQL与PostgreSQL都是高可配置的，并且可以针对不同的任务进行相应的优化。他们都支持通过扩展来添加额外的功能。
一个常见的误解就是MySQL要比PostgreSQL更容易学习。关系数据库系统都是非常复杂的，这两个数据库的学习曲线其实是差不多的。
标准兼容性
PostgreSQL旨在实现SQL兼容性（当前标准是ANSI-SQL:2008）。MySQL则兼容大部分SQL，不过还有自己的扩展，可以支 持NoSQL特性，这在参考手册中都有介绍。每种方式都有优缺点。兼容标准会让数据库管理员、数据库开发者与应用开发者更舒服一些，因为这意味着他们只需 学习一套标准、一套特性和命令即可。这会节省时间，提升效率，也不会被锁定在特定的厂商上。
支持使用非标准的自定义功能的人们认为这样可以快速采用新的特性，而不必等待标准进程完成。ANSI/ISO标准在不断演化，因此标准兼容性也是个 变化的目标：知名的关系型数据库Microsoft SQL Server、Oracle与IBM DB2也只是部分兼容于标准。
结论
虽然有不同的历史、引擎与工具，不过并没有明确的参考能够表明这两个数据库哪一个能够适用于所有情况。很多组织喜欢使用PostgreSQL，因为 它的可靠性好，在保护数据方面很擅长，而且是个社区项目，不会陷入厂商的牢笼之中。MySQL更加灵活，提供了更多选项来针对不同的任务进行裁剪。很多时 候，对于一个组织来说，对某个软件使用的熟练程度要比特性上的原因更重要。
3315
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
