这8个MySQL陷阱，你一定得多多注意了~

[[203180]]

Mysql 安装简单，速度较快，功能丰富。另外它还是开源运动的标杆，它的伟大成就向我们展示了一个成功的公司是可以建立在开源代码之上的。

然而用过 mysql 的人都曾对着显示器挥舞过拳头。但你不可能发明一种每秒能保存成千上万行互联网数据，并且一点错误都没有的技术吧。

为了在这个秋天躁起来，我们列举了 8 个抱怨开源关系型数据库的理由。下面列举的理由中不仅限于 MySQL，有一些是针对关系型数据库的。如果我们没有理清楚关系型数据库和 MySQL，我们将会永远陷入 90 年代的思想上。我们需要推倒然后重建这些。或者我们转向使用一个最近流行的，存在时间没有长到可以列出一堆像下面一样的理由的数据库。

根深蒂固的 bugs

任何大的软件包都有 bug。但稍微深入了解一下，就会发现和 Mysql 相关的 bugs 自成体系。突然你就需要留心，因为 NULL 并不是以同样的方式出现，外键约束也没有像你想像的那样执行，连主键自动增长也会出错。

小问题大量存在，而且并不总是可以修复，这就是为什么一些人保持一个列表。还好 MySQL 维护着一个非常好的 bug 报告系统，让我们可以知道我些我们无法想像的事情，知道其他人也在经受同样的磨难。

关系表的不灵活性

关系表具有条理性，条理性是好的——但是，它使得程序员不得不编造或硬塞一些数据到已经定义好模式的列中。NoSQL 开始越来越受到欢迎的原因之一，就是它为程序员提供了足够的灵活性，来加速数据库的使用。如果一个街道地址需要增加一行，那么，你可以将它很容易地插入到一个 NoSQL 文档中。如果你想添加一个完整的新的数据块，无论它包含什么内容，文档模型也可以原封不动地接受你的数据，而不必改为它要求的数据格式。

试想一下，你用整数格式建立了一个全部是邮编的表格。这个表是十分高效的，它执行的规则也很好。突然一次，有人上传了一个使用了连字符的九位数邮编。或者还有可能，你得到了一位来自加拿大客户的信件，上面写有邮政编码。

这时，一切都乱了。老板要求网站要在几小时内恢复正常工作。然而，现在已经没有时间来重建数据库。程序员可以做什么?也许，可以使用黑客手段把加拿大邮政编码由 base64 的数字格式改为 base 10 格式?或者设置一个使用转义编码的辅助表格，用来说明真正的邮政编码或者其他?谁知道呢?到处都有黑客，他们都是危险的。但你没有时间来搞定它。

MySQL 的关联规则让每个人都诚实和谨慎，但它能强制我们避开易受攻击和欺骗的麻烦。

JOIN 联合查询

曾几何时，将数据分表保存是计算机科学史上的伟大创新。分开后的表不仅结构简单，也简化了使用。但它却需要使用 join 语句进行查询。

sql 通过一系列 join 构建的复杂查询将开发者推入了困惑与绝望的深渊。而且存储引擎也需要以最优的方式来高效地解析 join 语句。开发者需要绞尽脑汁编写查询语句，然后数据库对其进行解析。

这就是很多注重运行速度的开发者放弃数据分表转而使用不规范数据表的原因。不区分数据实体，将所有数据保存到一个大表中——以避免复杂的查询。这样确实很快，并且服务器也不会耗尽内存。

磁盘空间现在很廉价。8TB 的磁盘已经在售，更大的也要上市了。我们不再需要为使用 join 而绞尽脑汁了。

分支的混乱

是的，一个可靠的、得到良好支持的 MySQL 分支，可以带来竞争和选择，但是它也引起困惑和混乱。更糟糕的是，一个称为 MariaDB 的MySQL 分支，由 Monty Widenius 维护着。他同样也在参与编写 MySQL。那么，MariaDB 是真正独立的值得我们拥护的吗?或者它是 MySQL?我们是否应该坚持使用由创建原始 MySQL 数据库的组织运营的核心代码?或者我们应该加入那些被认为更聪明的，往往很酷的背叛者?

还有，我们应当如何获得关于兼容性的信息?一方面，我们被确信 MariaDB 和 MySQL 十分地相似。另一方面，我们要相信有差异——不然为什么大家都在争论它?也许它们在性能和我们查询的范围内，在两个阵营中工作方式相同?但也许他们不同 – 或者将来会不同。

存储引擎混乱

MySQL 不是事实上的同一的数据库;它由几个数据库组成，它们的大多数细节都被统一的表面所掩盖。在开始的时候，有一个 MyISAM 引擎，它很快但是在前后一致上不能做到完备。有时候你需要速度并且可以接受不一致的结果时是很好的。

当人们需要更多时，具备完整事务支持的 InnoDB 出现了。但这还不够。现在，它可能有 20 种存储引擎的选择——这足以使一个数据库管理员疯狂。当然，有些时候在不同的存储引擎之间切换而不必重写你的 SQL 是很好的，但是切换后总会带来混乱。这个表格我选择的引擎是 MyISAM 还是 innoDB 呢?或者，我决定输出的数据是 CSV 格式的吗?

盈利的动机

虽然 MySQL 是一款成功的开源产品，但它仍然是一门生意，里面满是靠它获得薪水的专业开发者。当大多数用户在持续地享受开源许可证带来的最佳体验时，毫无疑问这家公司还在为赚取足够的钱来维持运营而努力。这导致自由代码在 “社区版” 和出售给企业的完整产品之间产生了奇怪的分岐。

你应该付钱吗?你在这里挣到了多少钱?在社区版之上开展经营行为是否公平?企业版中额外的功能，是否只是一个噱头来引诱我们不断付费呢?这至少说明一点，它是另一组需要回答的问题。选用哪个版本?遵照哪种许可证?选用它的哪个功能集?

原生 JSON 支持的缺乏

看 MySQL 的年龄最好的办法是安装它，然后你会意识到需要添加更多的驱动程序使它可用。MySQL 通常在 3306 端口上通信，它一般输出的是它自己难以理解的格式化数据。如果你想让你的代码和它通信，你必须添加另一层的代码，将 MySQL 的语言转换成有用的东西。这些层的代码，以库的形式分发，经常需要人们购买一个商业的许可证。

现代数据存储层通常直接以 JSON 通信。虽然 MySQL 和 MariaDB 现在有能力解析 SQL 中的 JSON 部分，但这还远远不够好，原生的 JSON 接口已经在 CouchDB，MongoDB，或任何最新的工具中广泛使用。

封闭源和专有模块的兴起

我说过 MySQL 是开源的吗?它是，但除了一些在” 开源核心 “周边开发的一些较新的、非开源的代码、专有模块。程序员需要吃饭，Oracle 需要拿它的辛苦成果来换钱，这是商业的现实之一。它不像那些医院，使用 MySQL 可以免费医疗护理。它不象那些农民，使用 MySQL 可以赠送食物。

要求 MySQL 始终坚持在一个很高的标准是有点不公平的，因为开源的成功可能是一个圈套。这是因为它开始可以免费，但并不意味着它可以始终如此。如果企业需要许多新的功能，他们将不得不用这种或那种方式付费。有时向 Oracle 付费，比自己来编写代码要便宜得多。有时商业的、不开源的代码是有意义的。事实不言而喻。