1.事务

1.事务特性--ACID

Atomicity(原子性):要么全做,要么不做,不能只做一半(银行转账)

Consistency(约束性):事务的前后,约束都能满足

Isolation(依赖性):事务之间是独立的,互不影响的

Durability(持久性):事务执行之后,事物的结果可以持久保存

2.事务隔离级别:

read uncommitted:可以读到未提交的事务结果

read committed:只能读已提交事务的结果

repeatable reads:可以读到开启事务时的值

serializable:两个事务同时发生,必定是有先后的

3.实践操作的准备

使用Join and Group中两个表,向product表中新添一个字段count,用来记录产品数量

2.Read Commit

预热:查询一下当前数据库的事务隔离级别,保证事务隔离级别是read-commited

我的数据库是Mysql5.5,默认事务隔离级别是repeatable-read,所以将其修改为read-commited

1.首先开启两个事务--事务A,事务B(注意这里如果使用可视化界面,例如Heidi,可能两个窗口并不是真正的开启了两个事务,所以建议使用cmd来测试)

开启事务A -> 将自动提交设为否(似乎5.5以上版本事务隔离级别高,不自动提交) -> 查询productId=4的count

事务A:

开启事务B,执行与事务A同样的操作

事务B:

2.在事务B中操作,将productId=4的count更改为49,但是不提交事务

事务B:

3.此时在事务A中查询一下count值,看在事务B更改数据但是未提交的情况下,事务A是否能查看到更新后的数据

事务A:

结果:事务A不能查看到事务B未提交的数据

4.将事务B提交,操作事务A,看是否能查询到更新后的数据

事务A:

结果:事务B提交后,事务A能查询到更新后的数据了

结论:当事务隔离级别为read-commited时,一个事务只能读取到另一事务已提交的数据

3.Repeatable-read

预热:查询并将事务隔离级别修改为repeatable-read,将数据库中count字段初始化为50

1.分别在开启事务A,事务B

事务A:

事务B:

2.在事务B端更改count值,但是不提交事务

事务B:

操作事务A查询count,发现查询结果没变

事务A:

3.提交事务B,并且操作事务A查看count,发现查询到的count值依然没变

事务B:

事务A:

结论:当事务隔离级别为repeatable-read时,一个事务只能读到开启本事务时读到的数据,无法读取其他事务更新的数据

4.Serializable

预热:查询并将事务隔离级别更改为serializable,将product表中count更改为50

1.分别开启事务A,事务B

2.在事务B端执行更新操作

事务B:发现没有一直处于执行中,并没有执行成功

2.将事务A提交后,发现事务B更新成功

事务A:

事务B:

3.再提交事务B,操作事务A

事务B:

事务A:

结论:在serilizalbe级别下,select语句不仅会开启事务,还会降数据锁上,只允许其他事务查询,不允许更改

5.For update

事务隔离级别没必要提升到serilizable,只需要使用read-committed,select语句加for update即可

预热:将事务隔离级别更改为read-committed

1.开启事务A,并将查询语句中加入for update

事务A:

事务B:

结果:只有当事务A提交之后,事务B才能查询到数据

结论:在select语句中加入for update时,只有当次事务提交之后,其他事务才能查询数据,for update会将数据加锁,防止其他事务操作发生数据不一致

6.乐观锁

在语句中加入版本控制,如果版本是当前版本则可以进行修改,否则进行回滚,还有加锁可是很浪费时间的哦

转发一篇文章悲观锁和乐观锁;,自己很喜欢的公众号---码农翻身

7.例题