mysql mongodb选择_关于选择MySQL还是MongoDB

有一天突然想到这个问题：能用关系型DB的地方，就能用Non-SQL，Non-SQL还有更灵活的表结构，那我们为什么还要选择关系型DB呢？

关于这个问题，Non-SQL的代表MongoDB自己也给出过解释(https://www.mongodb.com/compare/mongodb-mysql?jmp=docs)，看下来的感觉依然是MongoDB完全超越MySQL。特别在于用户互动相关的社交领域，MongoDB更胜一筹。

当然，它也提到了“什么样的情况选择MySQL会更好”：

需要复杂的多行事务的应用程序(例如双记录记录系统)

涉及复杂交易的系统，比如旅行预订系统背后的预订引擎

那么，问题来了：为什么交易系统更适合用关系型数据库？

要回答这个问题，首先需要知道MySQL比MongoDB好的优点，在于Complex Transactions(复杂事务)。

所谓事务，就是一组连续的DB操作。说白了就是一批SQL。事务处理主要用来维护数据库的完整性，保证成批的 SQL 语句要么全部执行，要么全部不执行。

事务的应用场景，主要就是交易系统、订单系统、银行系统。

举几个例子：

例1：A账户扣除￥100，然后A账户增加￥200。如果第一步执行成功后，系统故障，A就无法获得增加的￥200，怎么办？

例2：删除好友，需要先从A的好友列表中删除B，然后再从B的好友列表中删除A。这两个步骤缺一不可。

这两个例子中，每组操作，就是一个事务。事务里的这些操作，要么全部执行，要么全部失败，不能只执行其中的一部分。所以事务提交之后，会将提交的事务持久化到磁盘。即使系统崩溃，提交的数据也不应该丢失。

这样的场景在交易系统、订单系统、银行系统中，很常见。这种情况，需要复杂事务操作，MongoDB无法做到，就应该选择关系型数据库。