关闭自动提交#
在MySQL命令行的默认设置下，事务都是自动提交的，即执行SQL语句后就会马上执行COMMIT操作。因此开始一个事务，必须使用BEGIN、START TRANSACTION，(显示开启事务）或者执行SET AUTOCOMMIT=0，以禁用当前会话的自动提交。
- select语句一般用来输出用户变量，比如select @变量名，用于输出数据源不是表格的数据。
- 系统变量在变量名前面有两个@
mysql> show variables like 'autocommit';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit | ON |
+---------------+-------+
1 row in set (0.00 sec)
mysql> select @@autocommit;
+--------------+
| @@autocommit |
+--------------+
| 1 |
+--------------+
1 row in set (0.00 sec)
# 修改变量
set autocommit=0;本文中autocommit=0，开始事务需要使用begin显式开启
事务并发存在的问题#
没有脏读问题，如果两个事务同时修改一条数据，那么另一个事务的修改操作会被阻塞
【隔离性】脏读（读到了还没有提交的数据）
【隔离性】不可重复读（同一事务中，第1次读的数据和第2次读的数据不一样。读到了事务操作过程中其他事务提交的数据，也不应该，这个没法保证一致性。比如我第一次根据某个事务做了一个操作，第二次想同样的逻辑做一个判断操作，但是数据变了，导致同一个事务中对同一个(其实不是了）数据做的操作居然不一致
【隔离性】虚读、幻读（同一事务中：我第一次读到某一条数据，但是第二次没读到；或者第一次没读到，第二次居然读到了。条数问题）
事务的隔离级别#
READ_UNCOMMITTED 读未提交
READ_COMMITTED 读已提交
REPEATABLE_READ 重复读
SERIALIZABLE 串行化(行锁)
修改事务隔离级别：
set tx_isolation='SERIALIZABLE'; (可以加global，让新开的session也使用该事务隔离级别)经测试，如果有三个session（mysql客户端），其中一个(a)是SERIALIZABLE,而其他两个(b,c)是READ_UNCOMMITTED，那么客户端b,c之间不会因为锁挂起，而ab或ac会导致(行)锁挂起
REPEATABLE_READ重复读#
REPEATABLE_READ重复读的隔离级别只能在一定程度上防止幻读 如果事务a(插入一条新数据，或者删除一条数据)后提交。那么变动的数据不会在事务b被查出来。但是如果插入的这条数据(在事务b，注意 不是事务a)被修改了，那么之后它会在事务b被查出来
新增后修改#
事务a新增数据后提交，在事务b执行中修改了该数据，则该数据会显示出来（影响了）
#=======事务b=======
mysql> begin;
mysql> select * from user;
+----+-----+
| id | age |
+----+-----+
| 1 | 10 |
| 2 | 20 |
| 3 | 33 |
+----+-----+
#=======事务a=======
mysql> insert into user(age) values(44);
#=======事务b=======
mysql> select * from user;
+----+-----+
| id | age |
+----+-----+
| 1 | 10 |
| 2 | 20 |
| 3 | 33 |
+----+-----+
#=======事务a=======
mysql> update user set age=55 where id = 4;
#=======事务b=======
mysql> select * from user;
+----+-----+
| id | age |
+----+-----+
| 1 | 10 |
| 2 | 20 |
| 3 | 33 |
+----+-----+
#=======事务b=======
mysql> update user set age=55 where id = 4;
mysql> select * from user;
+----+-----+
| id | age |
+----+-----+
| 1 | 10 |
| 2 | 20 |
| 3 | 33 |
| 4 | 55 |
+----+-----+
##此时如果事务a进行 delete from user where id = 4; 那么事务a会阻塞，直到事务b commit删除后修改#
事务a删除数据后提交，在事务b执行中修改了该数据，该数据也照样存在（不影响）
