准备工作

• 将mysql的默认隔离级别设置成读未提交

set global transaction isolation level read uncommitted;

注意：设置完毕之后，需要重启终端，进行查看

select @@tx_isolation  

• 创建测试表

mysql> create table if not exists account(
    -> id int primary key,
    -> name varchar(50) not null default '',
    -> blance decimal(10,2) not null default 0.0
    -> )engine=InnoDB default charset=utf8;
Query OK, 0 rows affected (0.22 sec)

并且同时启动两个客户端,即两个SSH渠道。

事务常见操作方式

先查看当前事务的提交方式：这里我们之前设置成自动提交了

show variables like 'autocommit';

启动事务：

-- 方式一
start transaction;

-- 方式二
begin;

创建一个保存点：

savepoint s1;

现在，我们给一端插入数据并且设置保存结点：

此时的account表中的数据如下：

现在，事务进行回滚rollback to s3:

此时的account表中的王五这条数据就没有了：

如果回滚到上面设置的保存点s1,那么account表中的数据自然就没有了。这就是回滚事务。

结束事务：

commit;

• 这上面的操作是设置保存点的，如果没有保存点

此时查看表account的数据：数据全没了

直接rollback，把从开始启动事务的所有操作全部丢弃。

• 事务持久化

此时再来查看表account:

此时即使后续在进行rollback操作，也没有影响了。

此时的数据永久化保存在数据库里了。也就是事务一经提交，就没办法再回滚了。也就是回滚只能在事务运行进行的期间，事务提交之后，无法回滚

• **事务运行期间出现异常，客户端崩溃，MySQL自动会回滚 **

先来看一下现在有一个表account，以及两个客户端，也就是以下的情况：（注意，事务是自动提交的show variables like ‘autocommit’;）

现在来看一下客户端崩溃，自动回滚的情况：

ctrl + \ 异常终止MySQL

另外，只要把事务统一commit之后，这个数据就直接被插入到数据库中，并不会因为客户端崩溃这种情况而出现数据回滚。

• 证明begin操作会自动更改提交方式，不会受MySQL是否自动提交影响

关闭自动提交

set autocommit=1;

插入数据commit后客户端崩溃：

此时的田七这条数据是存在的了

• 证明单条 SQL 与事务的关系

场景一：先关闭自动提交

account表中的数据如下：

现在执行单sql语句：数据被删除，但是如果aborted，当前的数据会自动回滚！

场景二：先打开自动提交

表account的数据如下：

现在执行单sql,aborted之后，删除就是删除了

autocommit会影响之前的单sql，每条sql就相当于事务，虽然没有写begin，没有写commit。单sql执行的时候，如果autocommit是off的，只是事务执行中，当这个客户端崩溃的时候，数据会回滚。如果autocommit是on的，信息直接提交到数据库进行持久化。

单sql也是事务，是自动提交的。如果autocommit是off关闭的，当sql执行后再commit之后数据就是持久化了。

总结

结论

只要输入begin或者start transaction，事务便必须要通过commit提交，才会持久化，与是否设置set autocommit无关。

事务可以手动回滚，同时，当操作异常，MySQL会自动回滚

对于 InnoDB 每一条 SQL 语言都默认封装成事务，自动提交,除非把autocommit改成OFF。（select有特殊情况，因为MySQL 有 MVCC )

从上面的例子，我们能看到事务本身的原子性(回滚)，持久性(commit)

事务操作注意事项

如果没有设置保存点，也可以回滚，只能回滚到事务的开始。直接使用 rollback(前提是事务还没有提交)
如果一个事务被提交了（commit），则不可以回退（rollback）
可以选择回退到哪个保存点
InnoDB 支持事务， MyISAM 不支持事务
开始事务可以使 start transaction 或者 begin，结束使用commit，建议使用begin，毕竟比较容易记住