吐槽时间到——剑指大家都喜爱的高人气关系数据库

mysql易于安装、速度相对出色而且包含丰富的功能选项。如果单凭这些还不足以吸引你，它同时也是开源运动当中最具代表性的旗舰性项目之一——它的成功故事告诉我们，一家以开源为立足根基的企业同样能够获得巨大成功。

令人不禁怒吼wtf的八大mysql常见问题

然而，相信每一位使用过mysql的朋友都曾经出于某种理由将自己的怒拳挥向屏幕——哐!!!虽然平心而论，我们不可能建立起一套能够存储成千上万条互联网信息的技术体系，又要求其从来不出任何差错。但是，一旦差错出现，一股恨意总会涌上大家的心头——也包括我自己。

在今天的文章中，我们整理出关于这套开源关系数据库的八大漏洞，而这些正是经常导致用户神经错乱的元凶所在。其中一部分并不限于mysql本身，它们会在各类关系类数据库当中频频出现。但如果不把关系类数据库跟mysql进行明确划分，那么我们将永远生活在上世纪九十年代。所谓不破不立，正视问题也就是解决问题的第一步(当然，大家也可以选择存在时间还不太长的其它新型数据库，但它们同样也是问题缠身——必然的)。

深层缺陷与特有问题

任何一套规模庞大的软件包都会存在漏洞。不过从深层角度来看，mysql的各类漏洞已经形成了自己的一套风格与体系。在选择mysql的同时，大家必须马上集中注意力——因为在这里，null的作用在不同情况下会发生改变，而外键约束的效果亦往往与我们的期望不符……就连自动递增都会闹出各种意料之外的麻烦。

mysql当中存在着几十个这样的小问题，而且它们时不时就要跳出来折腾一番。有鉴于此，一部分用户专门整理出了清晰的错误清单。但mysql至少拥有一套出色的漏洞报告系统，因此我们可以了解到那些自己尚未意识到或者遇到过的潜在问题。遇上错误别激动，其他人也在经历着同样的命运。

关系表欠缺灵活性

表带来了纪律性，纪律性绝不是坏事——但强迫程序员们不得不按照僵化的预定义列打理数据就很令人头痛了。nosql之所以能够在短时间内迅速风靡全球，就是因为它为程序员提供充分的灵活性，允许他们随时对数据模型加以强化。如果需要为联系地址添加一行新内容，大家可以在nosql当中轻松通过插入来实现。而如果各位打算添加任何一个完整的新数据块，nosql模型也能够顺利加以接纳，而不会强行要求用户以预设方式进行提交。

想象一下，我们可能刚刚创建出一套以整数形式存储邮政编码的表。它的效率很高，而且所采用的强制规则也完全可以接受。接下来，有人发送了一条包含连字符的九位邮政编码、或者收到一封包含有加拿大地址邮编的信件，这时我们该怎么办?

这时，相信大家和我一样，听见了梦想破坏的声音……老板希望网站能在几小时内顺利上线，因此我们根本没时间对整套解决方案进行重构。那么程序员该怎么做?也许需要利用一些小技巧将加拿大的邮政编码转化为base64数字，再将其转换回base10?又或者利用一条专门的转义码设置辅助表，从而声明真正的邮政编码其实被保存在其它位置?谁知道呢。我们有几十种解决问题的办法，但这些小诀窍总会带来其它潜在麻烦。不过没辙，时间紧迫，网站不能按时上线、我们是要丢饭碗的。

mysql的关联规则原本希望能让每位用户都抱有诚实谨慎的好心态，但实际上却让我们不得不通过小聪明来规避这种约束。

join

曾几何时，将数据拆分成多个表代表着计算机科学领域的一大卓越进步。这不仅意味着我们能够显著降低表的大小，同时也为用户带来良好的简化效果。但在join语句当中，这种纪律性与收益开始要求我们为之付出代价。

在sql当中，还没有哪部分组件能像join这样逼迫开发人员建立一系列复杂语句，并承受由此带来的混乱与绝望。在此之后，存储引擎还需要找到最优方式来高效解压这些join语句。总而言之，这相当于开发人员被迫建立起复杂的查询表述，而数据库则被迫对其进行梳理。

正因为如此，很多追求速度表现的开发人员干脆放弃了这一进步，转而采用非规范化方式处理。相较于对条目进行拆分，大家直接将数据对象汇总成一个巨大的表，而这就规避了其复杂性。如此一来，运行速度不仅更快，服务器也不至于(频繁)出现内存溢出状况。

如今磁盘存储空间已经相当廉价。市场上已经出现了单磁盘8 tb产品，而容量更大的方案也即将亮相。所以相信在不久的将来，我们将彻底告别该当活剐的join。

更多信息请查看IT技术专栏