Mysql 事务失效的场景

DDL

所有的 DDL 语句都会导致事务隐式提交，换句话说，当你在执行 DDL 语句前，事务就已经提交了。这就意味着带有 DDL 语句的事务将来没有办法 rollback。

到第六步的时候，我们发现查询到的数据只剩三条了，说明第五步的回滚并没有生效。原因就在于执行 alter 之前，事务已经被隐式提交了。
所以小伙伴们在日常开发中，最好不要在事务中混有 DDL 语句，DDL 语句和 DML 语句分开写。
对于上面的案例，如果大家去掉第四步的 alter，那么回滚是可以回滚成功的，这个小伙伴们自己来测试，我就不演示了。
当然 DDL 操作可不仅仅是 alter，其他的如 CREATE、DROP 等操作也会导致事务隐式提交，这里松哥就不一一举例了，小伙伴们可以自行尝试。

DCL

DDL 和 DML 大家应该经常接触到，但是 DCL 可能有小伙伴不清楚，DCL 其实就是 Data Control Language，中文译作数据控制语言，我们日常授权或者回收数据库上的权限所使用的 GRANT、REVOKE 等，就算是 DCL 操作。

可以看到，跟第一小节的测试步骤一样，只不过第四步换成一个 GRANT 语句，那么最终的事务回滚也会失效，原因就在于事务已经提交了。
当然，除了 GRANT 和 REVOKE 之外，其他的创建、更新或者删除用户的操作也会导致事务隐式提交。主要有：

• CREATE USER…
• DROP USER…
• ALTER USER…
• SET PASSWORD…

开新事务

一个事务还没提交，结果你又开启了一个新的事务，那么此时前一个事务也会隐式提交。看个例子：

各种锁操作

给表上锁、解锁也会导致事务隐式提交

上锁的 SQL 如 lock tables table_name read|write，会导致事务隐式提交，解锁的 SQL 如 unlock tables 也会导致事务被隐式提交。
除了表锁，一些全局锁如 FTWRL 也会导致事务的隐式提交，如下：

从机的操作

我们在从机上执行的一些操作如 start slave、stop slave、reset slave 以及 change master to 等语句也会隐式提交事务。

其他表操作

其他的一下操作如刷新权限（flush privileges）、优化表（optimize table）、修复表（repair table）等操作，也会导致事务的隐式提交。

总结

那么多隐式提交，我怎么记得住呀？其实不用背，你只要记着事务里只写增删改查（INSERT/DELETE/UPDATE/SELECT），就不会错啦！