随着互联网与移动互联网的发展，很多机构都需要支撑远超过以往的数据。然而在这个需求的刺激下，IT 领域出现了大量数据处理技术，其中之一就是 NoSQL数据库。灵活的数据类型，高效的处理能力，让 NoSQL 已占据数据管理系统的一席之地，例如人气 NoSQL 数据库 MongoDB，mysql。然而在 Wix 工程实践中，他们发现了其实在大量场景中并不需要NoSQL，其实成熟的 RDBMS 更具效益，比如 MySQL。下面我们一起看 Wix 工程主管 Aviran Mordo 的分享。

　　一般都是根据主观臆断，开发人员就选择 NoSQL 数据库，或者有一个“关系型数据库性能不如 NoSQL 数据库”错误的理念。另外，在做数据库选型时，开发人员往往还忽视了运维上的开销。事实上根据 Wix 的实践发现，大部分情况下都不必去选择 NoSQL 数据库，而且若使用得当的话，MySQL 也可以是一个优秀的 NoSQL 数据库。

　　在可扩展系统构建时，一个很重要的考量是技术是否成熟，选择成熟的技术意味着出错时可以迅速恢复。当然，开发者也可在项目中使用最新最牛的 NoSQL 数据库，而这个数据库在理论上也可以良好地运行，但是在生产环境中出现了问题恢复需要多久?技术上已有的知识与经验积累对于问题缓解至关重要，当然这个积累也包括了 Google 能搜索到的内容。相比之下，关系型数据库存在的时间超过四十年，对于关系型数据库的维护业界也积累了大量的经验。基于这些考虑，在新项目做技术选型时大家通常会选择 MySQL，而不是 NoSQL 数据库，除非 NoSQL 真的有非常非常明显的优势，例如数据量太大就不适合使用 MySQL。

　必须承认的是 MySQL 也有自己的问题。若在大规模系统中使用的话可能会碰到性能上的问题。我们在这里总结了几条经验来帮助大家实现 MySQL 性能的最优化，经验之一是避免数据库级别的事务。由于事务需要数据库采用锁来实现，从而会影响数据库性能。通常情况下会使用逻辑应用程序级的锁来 替换，从而减少负载并获得一个更好的性能。

  　比如，以发票结构为例。若某个发票有多个行项目，取代在单事务将所有行项目写入，这里更应该在非事务情况下逐行写入。在所有行全部写入数据库后，这里还会写入一个首记录，它包含了指向所有行项目 ID 的指针。这样一来，如果所有行中有一行写入失败，那么这行的首记录就会不存在，从而整个事务失败。虽然这么做可能会造成一些垃圾记录，但在存储介质如此便宜的今天这显然不是什么大问题，而这些垃圾记录也可以做定期删除。

　　下面也是一些 MySQL 实践经验：

1. 　　   不要使用 joins 查询，只做主键或者索引查询。
2.        不要使用自增主键因为会有锁，取而代之，使用客户端生成键，比如 GUIDs。同时，如果你使用主主备份，自增键还可能会冲突，所以你需要为每个实例都定制键的范围。
3.        没有索引的字段通通删掉或者使用 JSON 集合成单一字段。
4.        在 Wix，MySQL 经常会被当做键值存储，比如在一列中储存 JSON 对象，从而在不改变数据库模式下对数据结构模式进行扩展。
5.        在 MySQL 中，使用主键读取也很快，Wix 就通过这个方式获得了亚毫秒级的读取速度，完全可以支撑整个使用场景。

    基于以上这些原因，MySQL 完全可以看作一个符合 ACID 原则的 NoSQL 数据库。至于数据库的大小，一个 MySQL 实例去支持几亿条数据是没什么问题的。

　　关系型数据库的一个鲜明的优势是不用考虑最终一致性，然而这个在 NoSQL 数据库中并不是原生支持的。本文也不是贬低 NoSQL，由于关系型数据库已有限制也非常多：严格的数据结构与大小限制。在这里只是想提醒开发人员，在选择新技术时不要忽视运维成本。

　　原文链接：MySQL is a Great NoSQL Database