【MySql】MySql事务常见操作
文章目录
- 准备工作
- 事务常见操作方式
- 总结
准备工作
- 将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，毕竟比较容易记住