Mysql安装简单，速度较快，功能丰富。另外它还是开源运动的标杆，它的伟大成就向我们展示了一个成功的公司是可以建立在开源代码之上的。
然而用过mysql的人都曾对着显示器挥舞过拳头。但你不可能发明一种每秒能保存成千上万行互联网数据，并且一点错误都没有的技术吧。
为了在这个夏天躁起来，我们列举了8个抱怨开源关系型数据库的理由。下面列举的理由中不仅限于 MySQL，有一些是针对关系型数据库的。如果我们没有理清楚关系型数据库和 MySQL，我们将会永远陷入90年代的思想上。我们需要推倒然后重建这些。或者我们转向使用一个最近流行的，存在时间没有长到可以列出一堆像下面一样的理由的数据库。
英文标题：8 MySQL gotchas worth a rant
小问题大量存在，而且并不总是可以修复，这就是为什么一些人保持一个列表。还好 MySQL 维护着一人非常好的 bug 报告系统，让我们可以知道我些我们无法想像的事情，知道其他人也在经受同样的磨难。
试想一下，你用整数格式建立了一个全部是邮编的表格。这个表是十分高效的，它执行的规则也很好。突然一次，有人上传了一个使用了连字符的九位数邮编。或者还有可能，你得到了一位来自加拿大客户的信件，上面写有邮政编码。
这时，一切都乱了。老板要求网站要在几小时内恢复正常工作。然而，现在已经没有时间来重建数据库。程序员可以做什么？也许，可以使用黑客手段把加拿大邮政编码由base64的数字格式改为base 10格式？或者设置一个使用转义编码的辅助表格，用来说明真正的邮政编码或者其他？谁知道呢？到处都有黑客，他们都是危险的。但你没有时间来搞定它。
MySQL的关联规则让每个人都诚实和谨慎，但它能强制我们避开易受攻击和欺骗的麻烦。
sql通过一系列join构建的复杂查询将开发者推入了困惑与绝望的深渊。而且存储引擎也需要以最优的方式来高效地解析join语句。开发者需要绞尽脑汁编写查询语句，然后数据库对其进行解析。
这就是很多注重运行速度的开发者放弃数据分表转而使用不规范数据表的原因。不区分数据实体，将所有数据保存到一个大表中——以避免复杂的查询。这样确实很快，并且服务器也不会耗尽内存。
磁盘空间现在很廉价。8TB的磁盘已经在售，更大的也要上市了。我们不再需要为使用join而绞尽脑汁了。
还有，我们应当如何获得关于兼容性的信息？一方面，我们被确信MariaDB和MySQL十分地相似。另一方面，我们要相信有差异——不然为什么大家都在争论它？也许它们在性能和我们查询的范围内，在两个阵营中工作方式相同？但也许他们不同-或者将来会不同。
当人们需要更多时，具备完整事务支持的InnoDB出现了。但这还不够。现在，它可能有20种存储引擎的选择——这足以使一个数据库管理员疯狂。当然，有些时候在不同的存储引擎之间切换而不必重写你的SQL是很好的，但是切换后总会带来混乱。这个表格我选择的引擎是 MyISAM 还是 innoDB 呢？或者，我决定输出的数据是CSV格式的吗？
你应该付钱吗？你在这里挣到了多少钱？在社区版之上开展经营行为是否公平？企业版中额外的功能，是否只是一个噱头来引诱我们不断付费呢？这至少说明一点，它是另一组需要回答的问题。选用哪个版本？遵照哪种许可证？选用它的哪个功能集？
现代数据存储层通常直接以 JSON 通信。虽然 MySQL 和 MariaDB 现在有能力解析 SQL 中的 JSON 部分，但这还远远不够好，原生的 JSON 接口已经在 CouchDB，MongoDB，或任何最新的工具中广泛使用。
要求 MySQL 始终坚持在一个很高的标准是有点不公平的，因为开源的成功可能是一个圈套。这是因为它开始可以免费，但并不意味着它可以始终如此。如果企业需要许多新的功能，他们将不得不用这种或那种方式付费。有时向 Oracle 付费，比自己来编写代码要便宜得多。有时商业的、不开源的代码是有意义的。事实不言而喻。
