8 个不得不说的 MySQL 陷阱 已翻译 100%

oschina 投递于 2015/07/23 11:52 (共 12 段, 翻译完成于 07-27)
阅读 14113
收藏 106
3
加载中

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

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

pseudo
pseudo
翻译于 2015/07/23 18:17
2

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

请叫我益达张
请叫我益达张
翻译于 2015/07/23 23:03
1

根深蒂固的bugs

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

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

wancheng
wancheng
翻译于 2015/07/24 09:30
1

关系表的不灵活性

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

Iam魔方
Iam魔方
翻译于 2015/07/25 14:12
3

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

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

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

Iam魔方
Iam魔方
翻译于 2015/07/25 14:43
2

JOIN联合查询

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

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

pseudo
pseudo
翻译于 2015/07/26 10:53
1

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

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

pseudo
pseudo
翻译于 2015/07/26 11:03
1

分支的混乱

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

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

Iam魔方
Iam魔方
翻译于 2015/07/26 12:48
1

存储引擎混乱

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

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

Iam魔方
Iam魔方
翻译于 2015/07/26 13:17
1

盈利的动机

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

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

Iam魔方
Iam魔方
翻译于 2015/07/27 09:34
1
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(48)

waterWang
waterWang
没有绝对的好坏
丌官尚雄
丌官尚雄
反正我也不懂,我就一直用着。
y
ylmotol7

引用来自“oreax”的评论

这就是很多注重运行速度的开发者放弃数据分表转而使用不规范数据表的原因。不区分数据实体,将所有数据保存到一个大表中——以避免复杂的查询。这样确实很快,并且服务器也不会耗尽内存。
--------------------------------
落伍了,原来现在要的不是规范,而是能用就行
规范都是人自己定的
红山茶
红山茶
存在即合理,MySQL 这么多年大用户层出不穷是有道理的。对于软件产品,没有所谓的完美,只能说不断改进。还有就是,如果一个公司不为赚钱而去做一件事情,可能性有多大,即使其他免费的开源软件在开源社区也是要接受捐赠的。
海诺者
海诺者

引用来自“oreax”的评论

这就是很多注重运行速度的开发者放弃数据分表转而使用不规范数据表的原因。不区分数据实体,将所有数据保存到一个大表中——以避免复杂的查询。这样确实很快,并且服务器也不会耗尽内存。
--------------------------------
落伍了,原来现在要的不是规范,而是能用就行
现在很多表字段超过30列
crazymus
crazymus
不用join,一切都很美好
crazymus
crazymus
4MySQL
哆啦比猫
哆啦比猫

引用来自“Havencode”的评论

最烦就是什么都要扯上Json。除了Json你就不会用点别的?!

引用来自“五杀联盟”的评论

加1

引用来自“fengyqf”的评论

+2

引用来自“车开源”的评论

+1024
+10086
车开源
车开源

引用来自“Havencode”的评论

最烦就是什么都要扯上Json。除了Json你就不会用点别的?!

引用来自“五杀联盟”的评论

加1

引用来自“fengyqf”的评论

+2
+1024
指键
指键
已阅
返回顶部
顶部