聊聊几个MySQL“老生常被喷”点

看喷有感

        这几天看到有公众号文章疯狂攻击MySQL，点进去看了一下，里面所谓的ACID、RR正确性问题，给大家介绍下背后的原理，以及为什么MySQL要选择这样的实现方式。

MySQL新版恶性Bug，表太多就崩给你看！----最近的这一篇，以及这里面引用的下面两篇

MySQL的正确性为何如此拉垮？
为什么说PostgreSQL前途无量？

        由于本人行业背景关系，对pg了解一点，对MySQL也了解一点，故有一点不同看法。

关于ACID

文章中原图如下，得出结论说MySQL不符合ACID，这  -_- !!!   -_- !!!   -_- !!!  -_- !!!

        在 MySQL 的事务处理中，出现错误并不会自动回滚整个事务，而 PostgreSQL 则会在发生错误时自动回滚整个事务。这是否意味着 MySQL 不符合 ACID 原则呢？

        实际上，上图中的最后一个 commit 已经给出了答案：MySQL只是将【提交】或【回滚】的选择权交给了用户而已！一个事务可能包含成千上万的增删改查SQL语句，在MySQL中，当某个语句执行出错后，用户可以根据错误信息进行处理，选择继续提交还是回滚。许多情况下，用户希望错误不影响之前的语句，那么就可以像上图一样直接提交；如果认为有影响，则可以选择回滚。选择权在用户手中。

        而在PostgreSQL中，发生错误时会强制回滚，用户没有选择权，即使用户执行的是 commit，也会被回滚，如上图所示。如果较真起来，PostgreSQL在这种情况下会丢失所有事务数据，而业务实际执行的是 commit，回滚并不是业务的预期结果。试想一个场景：某用户辛辛苦苦执行了几百条语句，某个语句手误出错，直接强制回滚整个事务，用户会是什么心态？硬要告诉用户ACID标准就是这样，所以要全部失败？为什么不能妥协一下，把选择权交给用户，让用户决定提交或回滚呢？用户来决策是否提交或回滚就不符合ACID了吗？ -_- !!! -_- !!!

        此外这个公众号作者，列举的所有其它的用例sql都一条sql占一行，而这个用例偏偏把多条sql写在一行？为什么呢？这一行等