关于MySQL和Postgres的具体比较_MySQL
程序员文章站
2022-05-14 15:41:21
...
我使用哪个数据库：PostgreSQL 或 MySQL?这个老生常谈的问题已经困惑了开发者至少两年了。我全面地接触了这两个数据库系统（MYSQL有一年，而Postgres有二年了），而且对MySQL网站提出的关于两者之间的差异非常好奇。
1999年9月，当我们正开始对SoureForge架设基础的时候，我对这两个数据库作了性能测试。当时，尽管我已经习惯于使用Postgres完成所有工作，但两者的性能差异是如此之明显以至与我们不得不采用MySQL。其他的惯用MySQL的开发者也拥护这个决定。
在当时，这个性能测试要胜于平时任何人为的测试。我想看看这两个数据库在网站某一具体的网页上应用的情况。所提及的这个网页是SourForge讨论区。它包括3个表的简单相关结合。每个表有20-30，000行数据。以及递归的实现和嵌套的信息，所以数据库在此页上的应用确实是一个瓶颈。
开始实行，我从库中卸下了真实的数据。编辑了SQL表，并且将其导入MySQL 3.22.30和PostgreSQL7.0.2，运行在拥有1G RAM 的VA Linux quad-xeon 4100 server上的Red Hat Linux 6.2上。
使我陷入的第一个问题是，在Postgres中，有一个不可思议的问题：每行数据最多只能有8K。在信息公告板上，你时常会超过每行8K的限制。所以Postgres在导入数据时阻塞。为了能继续使用，我只得将数据的"body"抛弃，并且重新导入数据。Postgres 开发小组已经意识到了这个限制，并且在7.1的版本中修改了，而且他们告诉你，你可通过重新编译Postgres使得它支持32K/每行，尽管这样做会使整个系统的性能受到影响。
在这一点上，我又陷入了Postgres另一个小问题上，它的"serial"数据类型（等价于MYSQL的auto_increment)会造成一个"sequence"：当它的双亲表被抛弃时，它本身不被抛弃。因此，当你想重新创建这个表时，会引起一个名字冲突。有许多新的用户被这个问题所困惑，所以这些问题使Postgres在测试中失去一些优势。相反，MySQL聪明到它可以在你导入数据的时候对auto_increment进行自动增量，然而Postgres的sequence 不可以在你导入数据时重置，从而引起新插入操作的失败。
方法
为了尽可能地真实，我从网站上选择了实际的网页，并且使它轻巧地交叉于MySQL和Postgres之间。这基本上意味着所有mysql_query()调用将被pg_exec()替换。这个页包括许多选取与连接操作，与典型的网站做的差不多。
一旦这个测试页运行和调试，我便使用"AB"，就是"Apache Benchmarking"应用集，从我的工作站通过我的100M局域网到达quad-xeon服务器。为了在负载的数量上得到一个概念，我使用AB进行各种并发连接的测试，从10-120，当离开了这些页后，这个数稳定在了1000上。
为了更加地接近实际应用，我在脚本中安置了一个随机数生成器，它插入页面的10%的数据到数据库中。在PHPBuilder中所有讨论区页面有10%是作为发送新信息的。
进一步地，就以上所说，我都使用从现成的数据中提取的数据，你得不出比此更真实的情况了。
数值
实际测试结果：
并发连接 w/p:
10 客户 - 10.27 页/秒333.69 kb/s
20 客户 - 10.24 页/秒332.86 kb/s
30 客户 - 10.25 页/秒333.01 kb/s
40 客户 - 10.0 页/秒324.78 kb/s
50 客户 - 10.0 页/秒324.84 kb/s
75 客户 - 9.58 页/秒311.43 kb/s
90 客户 - 9.48 页/秒307.95 kb/s
100 客户 - 9.23 页/秒300.00 kb/s
110 客户 - 9.09 页/秒295.20 kb/s
120 客户 - 9.28 页/秒295.02 kb/s (2.2% 失败)
并发连接w/10% 插入:
30 客户 - 9.97 页/秒324.11 kb/s
40 客户 - 10.08 页/秒327.40 kb/s
75 客户 - 9.51 页/秒309.13 kb/s
MySQL
并发连接测试 w/p:
30 客户 - 16.03 页/秒 521.01 kb/s
40 客户 - 15.64 页/秒 507.18 kb/s
50 客户 - 15.43 页/秒 497.88 kb/s
75 客户 - 14.70 页/秒 468.64 kb/s
90 - mysql 崩溃
110 - mysql 崩溃
120 - mysql 崩溃
并发连接测试w/op:
10 客户 - 16.55 页/秒537.63 kb/s
20 客户 - 15.99 页/秒519/51 kb/s
30 客户 - 15.55 页/秒505.19 kb/s
40 客户 - 15.46 页/秒490.01 kb/s 47 失败
50 客户 - 15.59 页/秒482.24 kb/s 82 失败
75 客户 - 17.65 页/秒452.08 kb/s 363 失败
90 客户 - mysql 崩溃
并发连接 w/10% 插入运算:
20 客户 - 16.37 页/秒531.79 kb/s
30 客户 - 16.15 页/秒524.64 kb/s
40 客户 - 22.04 页/秒453.82 kb/sec 378 失败
我觉得测试结果中最有意思的事情是观察没有出错情况下已经装入运行的Postgres能负载多少。实际上，Postgres在没有错误的情况下负载好像要比MySQL高3倍。MySQL在负有40-50个并发连接时开始失常，而在没有其它影响的情况下，Postgres能使120个并发连接运行自如。我的猜测是：如果有足够的内存与够快的CPU，Postgres能够正常负载的远远不止120个并发连接。
表面上看，这显然是Postgres的一个巨大的胜利，但是如果你仔细观察一下更多细节的测试结果，可以发现Postgres生成每页的时间要长2-3倍，所以它需要扩展负载至少2-3倍则刚好能与MySQL打成平手。所以按照不出错误的情况下，两者并发生成尽可能多的页，则他们之间几乎没有什么差别。按照某一时刻生成一页的情况看，MySQL确实快2-3倍。
另外一个有趣的事情是：在以上叙述的"10%插入运算"的测试中，MySQL在分解运算方面快一些。研究表明，当插入运算操作发生时，MySQL锁定整个表，而Postgres有一个美妙的"better than row-level locking"的机制。这个不同很快引起了MySQL并发连接的堆积，从而导致崩溃。同样的，如果你正在从数据库中进行大量的选中操作，而另外的进程正在对表进行插入操作。Postgres可以完全地不受干扰，而MySQL会堆积连接直到像纸牌做的房子一样崩溃。
你会发现在PHP中的稳定的连接并不有助于MySQL多少，相反却明显地有助于Postgres。实际上，其于稳定的连接的Postgres测试要快30%。这就告诉我们，Postgres在开放性连接与确认进程上需要占用大量的系统开销。其中有一些是Linux的错误和它的和僵硬的进程安排。尽管如此，MySQL并不再乎你如何看待它。
MySQL
MySQL的优缺点已经为许多人所知道：它是一个快速的、轻量级的数据库，但是基本上可以为大多数的网站服务得很好。
无论如何，如果你计划在一个高流量的站点（说明，每天生成多于500，000页）上，那么忘了MySQL吧。因为它往往会崩溃或者在装入运行后死机。任何曾经访问过Slashdot的人都可以证明它的弱点。（mod_perl and MySQL)
话说回来，MySQL证明了可使极大多数网站的页生成速度最高在每秒15页。如果你经常地运行在每秒15页之上，那么你将会非常高兴地支付更大的服务器或者Oracle license的费用。
优势
明显地，MySQL胜过Postgres的优势就在于性能。而且在它的发行版中，还具有一些强有力的管理工具。（其中一些工具允许你察看进程并且可以在程度运行时进行动态调试。）比如热备份，文件毁坏恢复工具等。
我也非常热衷于MySQL的命令行工具。你可以使用描述和察看命令来观察数据库与表的结构。而Postgres的命令则明显地少(/d可以显示一张示范表）
局限性
从数据库行家听说的第一件事就是MySQL缺乏transactions，rollbacks， 和subselects的功能。如果你计划使用MySQL写一个关于银行、会计的应用程序，或者计划维护一些随时需要线性递增的不同类的计数器，你将缺乏transactions功能。在现有的发布版本的MySQL下，请不要有任何的这些想法。（请注意，MySQL的测试版3.23.x系列现在已经支持transactions了）。
在非常必要的情况下，MySQL的局限性可以通过一部分开发者的努力得到克服。在MySQL中你失去的主要功能是subselect语句，而这正是其它的所有数据库都具有的。换而言之，这个失去的功能是一个痛苦，但是它可以被克服。
稳定性
MySQL在长期使用的稳定性上失了分。比如，MySQL在运行了30-60天左右的时间后，没有理由地就放弃了随机ghost。许多开发者使用"statically"来编译MySQL就是为了这个原因，而且这个方法帮助了许多人。这个问题也可以通过设置一个好的调度程序让MySQL每月被杀死并重起一次来克服。这并不是一个完全可取的方法，但至少也是一个办法。
MySQL在守护进程的健壮性上也失了分，但这个缺点被MySQL从来不会出现不可靠的数据文件而弥补。最后一件让人担心的事就是你重要的数据文件会不期地出错，而MySQL却很好地解决了这一点。在一整年的运行MySQL之后，这从未见过数据文件或索引文件轻易地出错。而在同样的时间内，我已经为一些Postgres数据库做了2-3次的恢复了。（记住，备份永远是你最好的朋友，这点可以从PHPBUILDER数据的崩溃看出）
PostgresSQL
Postgres的测试结果可能会使许多人感到惊奇，尽管Postgres在一些网站开发者中声誉并不怎么好（最初的Postgres的发布版本中除了对落后的性能以外，而对其他
1999年9月，当我们正开始对SoureForge架设基础的时候，我对这两个数据库作了性能测试。当时，尽管我已经习惯于使用Postgres完成所有工作，但两者的性能差异是如此之明显以至与我们不得不采用MySQL。其他的惯用MySQL的开发者也拥护这个决定。
在当时，这个性能测试要胜于平时任何人为的测试。我想看看这两个数据库在网站某一具体的网页上应用的情况。所提及的这个网页是SourForge讨论区。它包括3个表的简单相关结合。每个表有20-30，000行数据。以及递归的实现和嵌套的信息，所以数据库在此页上的应用确实是一个瓶颈。
开始实行，我从库中卸下了真实的数据。编辑了SQL表，并且将其导入MySQL 3.22.30和PostgreSQL7.0.2，运行在拥有1G RAM 的VA Linux quad-xeon 4100 server上的Red Hat Linux 6.2上。
使我陷入的第一个问题是，在Postgres中，有一个不可思议的问题：每行数据最多只能有8K。在信息公告板上，你时常会超过每行8K的限制。所以Postgres在导入数据时阻塞。为了能继续使用，我只得将数据的"body"抛弃，并且重新导入数据。Postgres 开发小组已经意识到了这个限制，并且在7.1的版本中修改了，而且他们告诉你，你可通过重新编译Postgres使得它支持32K/每行，尽管这样做会使整个系统的性能受到影响。
在这一点上，我又陷入了Postgres另一个小问题上，它的"serial"数据类型（等价于MYSQL的auto_increment)会造成一个"sequence"：当它的双亲表被抛弃时，它本身不被抛弃。因此，当你想重新创建这个表时，会引起一个名字冲突。有许多新的用户被这个问题所困惑，所以这些问题使Postgres在测试中失去一些优势。相反，MySQL聪明到它可以在你导入数据的时候对auto_increment进行自动增量，然而Postgres的sequence 不可以在你导入数据时重置，从而引起新插入操作的失败。
方法
为了尽可能地真实，我从网站上选择了实际的网页，并且使它轻巧地交叉于MySQL和Postgres之间。这基本上意味着所有mysql_query()调用将被pg_exec()替换。这个页包括许多选取与连接操作，与典型的网站做的差不多。
一旦这个测试页运行和调试，我便使用"AB"，就是"Apache Benchmarking"应用集，从我的工作站通过我的100M局域网到达quad-xeon服务器。为了在负载的数量上得到一个概念，我使用AB进行各种并发连接的测试，从10-120，当离开了这些页后，这个数稳定在了1000上。
为了更加地接近实际应用，我在脚本中安置了一个随机数生成器，它插入页面的10%的数据到数据库中。在PHPBuilder中所有讨论区页面有10%是作为发送新信息的。
进一步地，就以上所说，我都使用从现成的数据中提取的数据，你得不出比此更真实的情况了。
数值
实际测试结果：
并发连接 w/p:
10 客户 - 10.27 页/秒333.69 kb/s
20 客户 - 10.24 页/秒332.86 kb/s
30 客户 - 10.25 页/秒333.01 kb/s
40 客户 - 10.0 页/秒324.78 kb/s
50 客户 - 10.0 页/秒324.84 kb/s
75 客户 - 9.58 页/秒311.43 kb/s
90 客户 - 9.48 页/秒307.95 kb/s
100 客户 - 9.23 页/秒300.00 kb/s
110 客户 - 9.09 页/秒295.20 kb/s
120 客户 - 9.28 页/秒295.02 kb/s (2.2% 失败)
并发连接w/10% 插入:
30 客户 - 9.97 页/秒324.11 kb/s
40 客户 - 10.08 页/秒327.40 kb/s
75 客户 - 9.51 页/秒309.13 kb/s
MySQL
并发连接测试 w/p:
30 客户 - 16.03 页/秒 521.01 kb/s
40 客户 - 15.64 页/秒 507.18 kb/s
50 客户 - 15.43 页/秒 497.88 kb/s
75 客户 - 14.70 页/秒 468.64 kb/s
90 - mysql 崩溃
110 - mysql 崩溃
120 - mysql 崩溃
并发连接测试w/op:
10 客户 - 16.55 页/秒537.63 kb/s
20 客户 - 15.99 页/秒519/51 kb/s
30 客户 - 15.55 页/秒505.19 kb/s
40 客户 - 15.46 页/秒490.01 kb/s 47 失败
50 客户 - 15.59 页/秒482.24 kb/s 82 失败
75 客户 - 17.65 页/秒452.08 kb/s 363 失败
90 客户 - mysql 崩溃
并发连接 w/10% 插入运算:
20 客户 - 16.37 页/秒531.79 kb/s
30 客户 - 16.15 页/秒524.64 kb/s
40 客户 - 22.04 页/秒453.82 kb/sec 378 失败
我觉得测试结果中最有意思的事情是观察没有出错情况下已经装入运行的Postgres能负载多少。实际上，Postgres在没有错误的情况下负载好像要比MySQL高3倍。MySQL在负有40-50个并发连接时开始失常，而在没有其它影响的情况下，Postgres能使120个并发连接运行自如。我的猜测是：如果有足够的内存与够快的CPU，Postgres能够正常负载的远远不止120个并发连接。
表面上看，这显然是Postgres的一个巨大的胜利，但是如果你仔细观察一下更多细节的测试结果，可以发现Postgres生成每页的时间要长2-3倍，所以它需要扩展负载至少2-3倍则刚好能与MySQL打成平手。所以按照不出错误的情况下，两者并发生成尽可能多的页，则他们之间几乎没有什么差别。按照某一时刻生成一页的情况看，MySQL确实快2-3倍。
另外一个有趣的事情是：在以上叙述的"10%插入运算"的测试中，MySQL在分解运算方面快一些。研究表明，当插入运算操作发生时，MySQL锁定整个表，而Postgres有一个美妙的"better than row-level locking"的机制。这个不同很快引起了MySQL并发连接的堆积，从而导致崩溃。同样的，如果你正在从数据库中进行大量的选中操作，而另外的进程正在对表进行插入操作。Postgres可以完全地不受干扰，而MySQL会堆积连接直到像纸牌做的房子一样崩溃。
你会发现在PHP中的稳定的连接并不有助于MySQL多少，相反却明显地有助于Postgres。实际上，其于稳定的连接的Postgres测试要快30%。这就告诉我们，Postgres在开放性连接与确认进程上需要占用大量的系统开销。其中有一些是Linux的错误和它的和僵硬的进程安排。尽管如此，MySQL并不再乎你如何看待它。
MySQL
MySQL的优缺点已经为许多人所知道：它是一个快速的、轻量级的数据库，但是基本上可以为大多数的网站服务得很好。
无论如何，如果你计划在一个高流量的站点（说明，每天生成多于500，000页）上，那么忘了MySQL吧。因为它往往会崩溃或者在装入运行后死机。任何曾经访问过Slashdot的人都可以证明它的弱点。（mod_perl and MySQL)
话说回来，MySQL证明了可使极大多数网站的页生成速度最高在每秒15页。如果你经常地运行在每秒15页之上，那么你将会非常高兴地支付更大的服务器或者Oracle license的费用。
优势
明显地，MySQL胜过Postgres的优势就在于性能。而且在它的发行版中，还具有一些强有力的管理工具。（其中一些工具允许你察看进程并且可以在程度运行时进行动态调试。）比如热备份，文件毁坏恢复工具等。
我也非常热衷于MySQL的命令行工具。你可以使用描述和察看命令来观察数据库与表的结构。而Postgres的命令则明显地少(/d可以显示一张示范表）
局限性
从数据库行家听说的第一件事就是MySQL缺乏transactions，rollbacks， 和subselects的功能。如果你计划使用MySQL写一个关于银行、会计的应用程序，或者计划维护一些随时需要线性递增的不同类的计数器，你将缺乏transactions功能。在现有的发布版本的MySQL下，请不要有任何的这些想法。（请注意，MySQL的测试版3.23.x系列现在已经支持transactions了）。
在非常必要的情况下，MySQL的局限性可以通过一部分开发者的努力得到克服。在MySQL中你失去的主要功能是subselect语句，而这正是其它的所有数据库都具有的。换而言之，这个失去的功能是一个痛苦，但是它可以被克服。
稳定性
MySQL在长期使用的稳定性上失了分。比如，MySQL在运行了30-60天左右的时间后，没有理由地就放弃了随机ghost。许多开发者使用"statically"来编译MySQL就是为了这个原因，而且这个方法帮助了许多人。这个问题也可以通过设置一个好的调度程序让MySQL每月被杀死并重起一次来克服。这并不是一个完全可取的方法，但至少也是一个办法。
MySQL在守护进程的健壮性上也失了分，但这个缺点被MySQL从来不会出现不可靠的数据文件而弥补。最后一件让人担心的事就是你重要的数据文件会不期地出错，而MySQL却很好地解决了这一点。在一整年的运行MySQL之后，这从未见过数据文件或索引文件轻易地出错。而在同样的时间内，我已经为一些Postgres数据库做了2-3次的恢复了。（记住，备份永远是你最好的朋友，这点可以从PHPBUILDER数据的崩溃看出）
PostgresSQL
Postgres的测试结果可能会使许多人感到惊奇，尽管Postgres在一些网站开发者中声誉并不怎么好（最初的Postgres的发布版本中除了对落后的性能以外，而对其他