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.例题
