Pg 没有 MySQL 的各种坑
MySQL 的各种 text 字段有不同的限制, 要手动区分 small text, middle text, large text… Pg 没有这个限制, text 能支持各种大小.
按照 SQL 标准, 做 null 判断不能用 = null, 只能用 is null
the result of any arithmetic comparison with NULL is also NULL
但 pg 可以设置 transform_null_equals 把 = null 翻译成 is null 避免踩坑
不少人应该遇到过 MySQL 里需要 utf8mb4 才能显示 emoji 的坑, Pg 就没这个坑.
MySQL 的事务隔离级别 repeatable read 并不能阻止常见的并发更新, 得加锁才可以, 但悲观锁会影响性能, 手动实现乐观锁又复杂. 而 Pg 的列里有隐藏的乐观锁 version 字段, 默认的 repeatable read 级别就能保证并发更新的正确性, 并且又有乐观锁的性能. 附带一个各数据库对隔离级别的行为差异比较调查: http://www.cs.umb.edu/~poneil/iso.pdf
MySQL 不支持多个表从同一个序列中取 id, 而 Pg 可以.
MySQL 不支持 OVER 子句, 而 Pg 支持. OVER 子句能简单的解决 “每组取 top 5” 的这类问题.
几乎任何数据库的子查询 (subquery) 性能都比 MySQL 好.
更多的坑:
http://blog.ionelmc.ro/2014/12/28/terrible-choices-mysql/
不少人踩完坑了, 以为换个数据库还得踩一次, 所以很抗拒, 事实上不是!!!
Pg 不仅仅是 SQL 数据库
它可以存储 array 和 json, 可以在 array 和 json 上建索引, 甚至还能用表达式索引. 为了实现文档数据库的功能, 设计了 jsonb 的存储结构. 有人会说为什么不用 Mongodb 的 BSON 呢? Pg 的开发团队曾经考虑过, 但是他们看到 BSON 把 [“a”, “b”, “c”] 存成 {0: “a”, 1: “b”, 2: “c”} 的时候就决定要重新做一个 jsonb 了… 现在 jsonb 的性能已经优于 BSON.
现在往前端偏移的开发环境里, 用 Pg + PostgREST 直接生成后端 API 是非常快速高效的办法:
begriffs/postgrest · GitHub
postgREST 的性能非常强悍, 一个原因就是 Pg 可以直接组织返回 json 的结果.
它支持服务器端脚本: TCL, Python, R, Perl, Ruby, MRuby … 自带 map-reduce 了.
它有地理信息处理扩展 (GIS 扩展不仅限于真实世界, 游戏里的地形什么的也可以), 可以用 Pg 搭寻路服务器和地图服务器:
PostGIS — Spatial and Geographic Objects for PostgreSQL
它自带全文搜索功能 (不用费劲再装一个 elasticsearch 咯):
Full text search in milliseconds with PostgreSQL 不过一些语言相关的支持还不太完善, 有个 bamboo 插件用调教过的 mecab 做中文分词, 如果要求比较高, 还是自己分了词再存到 tsvector 比较好.
它支持 trigram 索引.
trigram 索引可以帮助改进全文搜索的结果: PostgreSQL: Documentation: 9.3: pg_trgm
trigram 还可以实现高效的正则搜索 (原理参考 https://swtch.com/~rsc/regexp/regexp4.html )
MySQL 处理树状回复的设计会很复杂, 而且需要写很多代码, 而 Pg 可以高效处理树结构:
Scaling Threaded Comments on Django at Disqus
http://www.slideshare.net/quipo/trees-in-the-database-advanced-data-structures
它可以高效处理图结构, 轻松实现 “朋友的朋友的朋友” 这种功能:
http://www.slideshare.net/quipo/rdbms-in-the-social-networks-age
它可以把 70 种外部数据源 (包括 Mysql, Oracle, CSV, hadoop …) 当成自己数据库中的表来查询:
Foreign data wrappers
一、 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都没有问题。
上面说的都很齐全了。
没有人说FDW(Foreign data wrappers)吗？那我提一下吧。
第一次看到惊为天人：用统一的SQL，去访问其他关系数据库，其他NoSQL数据库，HBase，甚至是各种格式的文件，操作系统信息，在线数据集。
瞬间爆炸好吗，各种数据库大一统万岁！ AA网友第一份工作是在某两家大型游戏公司做数据挖掘的，干了三年，听着说是数据挖掘，其实做的最多的我觉得是项目数据分析以及做游戏的后台报表数据计算框架。大公司因为人才储备和数据量很大的原因，一般是hadoop+mysql的模式，hadoop计算大量原始数据，然后按维度汇总后的展示数据存储在mysql供前段web select出来展示。三年后我离职去了一家小型游戏公司，虽然体量比原来东家小多了，但是游戏也比较受欢迎，数据也很多。由于人才储备及成本的原因，小公司并没有hadoop之类的大数据工具，我这边搭建这些东西还是使用的mysql，每天凌晨1点左右数据导入算前一天数据报表，需要实时展示的一些数据用python写的代码计算。但是mysql做数据报表计算后台最大缺点就是没有grouping sets和一些窗口函数，替代方案很麻烦而且效率低，还有就是做很多统计数据各种表连接、外连接等等一大堆，不同数据库之间数据的利用计算。于是我回去查资料偶然间发现了postgresql，短期用了下简直惊呆了，感觉这数据库都不要钱还开源，简直良心。但后面慢慢使用，也发现了一些postgresql的缺点，当然这些缺点只是我作为使用者的感受去说的，可能有写人不认同。简单总结下：
优点：
1，单纯我使用的感受来说，postgresql的性能应该是远远甩mysql三条街的，而且也稳如死狗，相同的数据量复杂计算，postgresql时间一般只有mysql 1/4左右，当然这个时间只是我这边业务我的使用情况，其他环境可能不一样，我这边是多表join，维度聚合等等比较多。还有将大量log文件导入数据库，也是pgsql快得多。
2，postgresql有grouping sets函数，也是迫使我抛弃mysql第一原因。做报表后台计算，olap/oltp之类的这个函数简直是刚性需求。没有grouping sets函数，我感觉做报表后台计算，简直惨不忍睹。当然pgsql还有挺多很好用的窗口函数之类，用起来真心爽。
3，pgsql对json支持比较好，还有很逆天的fdw功能，就是把别的数据库的表当自己的用，减少了我这边很多工作。
4，pgsql的字段类型支持的多，有很多mysql没有的类型，但是实际中有时候用到。
缺点：
1，pgsql表名就让我这种强迫症的人很难受，pgsql对表名大小写不敏感的。但是很多时候建表用大写字母在我看来是很优雅的一种方式。比如手游行业里面，创建角色的数据库你一般得用CreateRole类似这样的名字吧，不同英文之间大写标识，但是pgsql会直接给你变成小写表名，除非你能忍受每次使用这个表加个双引号，所以我建表就弄成create_role这样子，但是有些含义较多的会导致表名很长，看着不舒服。当然这算不上大事，但是也是不太方便的一个小细节点。
2，pgsql对语法简直严苛到有时候你认为变态的地步，甚至要为它这个严苛的学院派作风做很多代码修改、预处理。举个例子，一款手游每天某个日志会产生几十G的数据，你要把数据导入进去数据仓库，一般就是按照字段名，再指定下分隔符，比如有些公司喜欢用 | 分割字段等之类，还有的打印json格式。但是你要知道实际生产环境中，服务器是有很小的几率（我这边大概是百万分之1左右吧）将日志打印的不规范的，比如简单的举个例子角色登录日志。一般类似这样子 时间|账号ID|角色ID|角色名字|等级|登录IP|机型 。但很小的几率服务器会将一些字段丢掉了，比如这个日志打印成了 时间|账号ID|角色ID|角色名字 这样子，mysql导进去就无所谓，顶多就是这百万分之一中的这条数据某条数据不完整而已，而且丢掉的一些字段也不见得重要，但是pgsql直接导入不进去，会直接报错停掉。每天1000万行数据，就因为一条打印的不完整，呵呵，对不起，他会直接报错一条也导入不进去。有些人会说用awk之类预处理，但是数据量大了之后这种预处理也会拖慢效率。还有一个更是头疼，1000万里面有一行将数字类型的等级打印成了字符串的东西，那么pgsql会非让你找出这一条删掉，然后才能将剩下的数据导入进去。mysql就完全没有这个问题，比如mysql level字段定义的int类型，几千万中有一条数据没注意打印成字符串，mysql会自己给你转成0存储的，不会有任何报错。
3，pgsql的分区简直就是灾难级别的。使用的继承之类的概念。建一个主表，然后建立很多小表，继承到主表，建索引得一个一个在小表上面建立。小表建表的时候指定了分割规则，你导入的时候还是得很傻的按照这个规则去指定那个表导入，pgsql不会对你说，你插入主表，我根据你的建表规则去分配数据。还有它的分表性能差的要死。据说10会内置分表，后面看吧，反正我感觉pgsql的分表惨不忍睹。
总结下来就是，我这边使用下来，pgsql性能、稳定性会远强于mysql，功能上也比mysql强大太多，但是真的太学院派风格了，什么都是感觉在实验室的环境一样，对数据对语法严苛变态的不近人情，估计得让写这个的教授体会下真实的生产环境，他们的产品就不会这么理想化了。
MySQL如果只有MyISAM一个引擎的话,那你们黑真的也有道理,但问题是InnoDB现在已经是MySQL默认的引擎,而且这个引擎综合能力很强,能用好这个引擎其实就已经能解决大多数需要数据库的业务逻辑.在MySQL先占领市场的前提下,大多数MySQL用户都是不愿意冒风险切换到另一个数据库的,除非PostgreSQL真的是那个场景上是万金油.
在数据量极大的时候(大于1亿条的级别),InnoDB的B+树性能的缺陷会暴露,这时MySQL的DBA可能会转向TokuDB这个第三方开源的MySQL引擎来处理这些大数据.也就是说,MySQL的小用户,数据量估计连千万都不到,他们是不可能没事折腾换数据库的.MySQL的大用户,他们熟悉MySQL,他们也更愿意使用MySQL,既然TokuDB/Infobright这些第三方引擎能满足他们的某些需求如大数据存储和分析,他们也没有换数据库的动力.除非PostgreSQL在他们需求上对MySQL有绝对压倒性优势.
PostgreSQL真那么强,其实完全可以像TokuTek(已被Percona收购)那样,开发一个第三方MySQL存储引擎在MySQL里挑战InnoDB嘛,至少TokuDB(分形树索引)在某些方面证明了自己比InnoDB(B+树索引)优秀,比如随机插入性能,数据压缩效果,大数据存储和分析. 一、PG相对于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 AB的人们和PostgreSQL的开发者们都在尽可能地把各自的数据库改得越来越好，所以对于任何商业数据库使用其中的任何一个都不能算是错误的选择。
MySQL的背后是一个成熟的商业公司，而PostgreSQL的背后是一个庞大的志愿开发组。这使得MySQL的开发过程更为慎重，而PostgreSQL的反应更为迅速。
这样的两种背景直接导致了各自固有的优点和缺点。
1、首先是速度，MySQL通常要比PostgreSQL快得多。MySQL自已也宣称速度是他们追求的主要目标之一，基于这个原因，MySQL在以前的文档中也曾经说过并不准备支持事务和触发器。但是在最新的文档中，我们看到MySQL 4.0.2-alpha已经开始支持事务，而且在MySQL的TODO中，对触发器、约束这样的注定会降低速度的功能也列入了日程。但是，我们仍然有理由相信，MySQL将有可能一直保持速度的优势。
2、MySQL比PostgreSQL更流行，流行对于一个商业软件来说，也是一个很重要的指标，流行意味着更多的用户，意味着经受了更多的考验，意味着更好的商业支持、意味着更多、更完善的文档资料。
3、与PostgreSQL相比，MySQL更适宜在Windows环境下运行。MySQL作为一个本地的Windows应用程序运行(在 NT/Win2000/WinXP下，是一个服务)，而PostgreSQL是运行在Cygwin模拟环境下。PostgreSQL在Windows下运行没有MySQL稳定，应该是可以想象的。
4、MySQL使用了线程，而PostgreSQL使用的是进程。在不同线程之间的环境转换和访问公用的存储区域显然要比在不同的进程之间要快得多。
5、MySQL可以适应24/7运行。在绝大多数情况下，你不需要为MySQL运行任何清除程序。PostgreSQL目前仍不完全适应24/7运行，这是因为你必须每隔一段时间运行一次VACUUM。
6、MySQL在权限系统上比PostgreSQL某些方面更为完善。PostgreSQL只支持对于每一个用户在一个数据库上或一个数据表上的 INSERT、SELECT和UPDATE/DELETE的授权，而MySQL允许你定义一整套的不同的数据级、表级和列级的权限。对于列级的权限， PostgreSQL可以通过建立视图，并确定视图的权限来弥补。MySQL还允许你指定基于主机的权限，这对于目前的PostgreSQL是无法实现的，但是在很多时候，这是有用的。
7、由于MySQL 4.0.2-alpha开始支持事务的概念，因此事务对于MySQL不再仅仅成为劣势。相反，因为MySQL保留无事务的表类型。这就为用户提供了更多的选择。
8、MySQL的MERGE表提供了一个独特管理多个表的方法。
9、MySQL的myisampack可以对只读表进行压缩，此后仍然可以直接访问该表中的行。
1、对事务的支持与MySQL相比，经历了更为彻底的测试。对于一个严肃的商业应用来说，事务的支持是不可或缺的。
2、MySQL对于无事务的MyISAM表。采用表锁定，一个长时间运行的查询很可能会长时间地阻碍对表的更新。而PostgreSQL不存在这样的问题。
3、PostgreSQL支持存储过程，而目前MySQL不支持，对于一个严肃的商业应用来说，作为数据库本身，有众多的商业逻辑的存在，此时使用存储过程可以在较少地增加数据库服务器的负担的前提下，对这样的商业逻辑进行封装，并可以利用数据库服务器本身的内在机制对存储过程的执行进行优化。此外存储过程的存在也避免了在网络上大量的原始的SQL语句的传输，这样的优势是显而易见的。
4、对视图的支持，视图的存在同样可以最大限度地利用数据库服务器内在的优化机制。而且对于视图权限的合理使用，事实上可以提供行级别的权限，这是MySQL的权限系统所无法实现的。
5、对触发器的支持，触发器的存在不可避免的会影响数据库运行的效率，但是与此同时，触发器的存在也有利于对商业逻辑的封装，可以减少应用程序中对同一商业逻辑的重复控制。合理地使用触发器也有利于保证数据的完整性。
6、对约束的支持。约束的作用更多地表现在对数据完整性的保证上，合理地使用约束，也可以减少编程的工作量。
7、对子查询的支持。虽然在很多情况下在SQL语句中使用子查询效率低下，而且绝大多数情况下可以使用带条件的多表连接来替代子查询，但是子查询的存在在很多时候仍然不可避免。而且使用子查询的SQL语句与使用带条件的多表连接相比具有更高的程序可读性。
8、支持R-trees这样可扩展的索引类型，可以更方便地处理一些特殊数据。
9、PostgreSQL可以更方便地使用UDF(用户定义函数)进行扩展。
这个问题很难说得清，而
且事实上除了MySQL和PostgreSQL外，使用Oracle、Sybase、Informix等也是明智的选择。如何你确定只在MySQL和PostgreSQL中进行选择，以下规则总是有效的。1、如果你的操作系统是Windows，你应该使用MySQL。
2、如果你对数据库并不了十分了解，甚至不知道事务、存储过程等究竟是什么，你应该使用MySQL。
3、如果你的应用对数据的完整性和严肃性要求不高，但是追求处理的高速度。例如是一个论坛和社区，你应该使用MySQL。
4、你的应用是一个严肃的商业应用，对数据完整性要求很高。而且你希望对一些商业数据逻辑进行很好的封装，例如是一个网上银行，你应该使用PostgreSQL。
5、你的应用处理的是地理数据，由于R-TREES的存在，你应该使用PostgreSQL。
6、你是一个数据库内核的狂热爱好者，你甚至希望拥有你自己版本的数据库，毫无疑问，你必须使用PostgreSQL，没准下一个PostgreSQL版本中某一个模块的作者就是你。
以上只是作者从自己的理解尽量客观公正地评价MySQL和PostgreSQL的优劣。其中的带有倾向性的意见只代表作者个人观点，有关这两个数据库，欢迎广大朋友提出自己的看法。
个人感觉，两者都了解下吧，比如说你想学习数据库，但是你只是专注于了Oracle，Sybase什么的数据库你根本不懂，那对你今后的就业或者搞研究，肯定是有很大的阻碍的，学习数据库我们不能专注于某一个产品，而是关注整个行业，或许这样对未来的发展，对数据库的趋势才能掌握的很清楚。
