侧边栏壁纸
  • 累计撰写 781 篇文章
  • 累计创建 1 个标签
  • 累计收到 1 条评论
标签搜索

事务

Dettan
2021-04-10 / 0 评论 / 0 点赞 / 117 阅读 / 1,828 字
温馨提示:
本文最后更新于 2022-04-30,若内容或图片失效,请留言反馈。部分素材来自网络,若不小心影响到您的利益,请联系我们删除。
/ DATA / 事务
四大特征
数据库事务transanction正确执行的四个基本要素。
ACID,原子性(Atomicity)、一致性(Correspondence)、隔离性(Isolation)、持久性(Durability)。
1.
原子性:整个事务中的所有操作,要么全部完成,要么全部不完成,不可能停滞在中间某个环节。事务在执 行过程中发生错误,会被回滚(Rollback)到事务开始前的状态,就像这个事务从来没有执行过一样。
2.
一致性:在事务开始之前和事务结束以后,数据库的完整性约束没有被破坏。
3.
隔离性:隔离状态执行事务,使它们好像是系统在给定时间内执行的唯一操作。如果有两个事务,运行在相 同的时间内,执行 相同的功能,事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。这种属性有时称 为串行化,为了防止事务操作间的混淆, 必须串行化或序列化请 求,使得在同一时间仅有一个请求用于同一数据。
4.
持久性:在事务完成以后,该事务所对数据库所作的更改便持久的保存在数据库之中,并不会被回滚。


1.
怎么解决这些问题呢?MySQL的事务隔离级别了解吗?
1.
未提交读(READ UNCOMMITTED)
这就是上面所说的例外情况了,这个隔离级别下,其他事务可以看到本事务没有提交的部分修改.因此会造成脏读的问题.
这个级别的性能没有足够大的优势,但是又有很多的问题,因此很少使用.
2.
已提交读(READ COMMITTED)
只能读取到已经提交的数据。Oracle等多数数据库默认都是该级别 (不重复读),写事务时加行级排他锁,事务结束才释放;读事务加行级共享锁,但是读完立即释放锁,而不是事务结束释放,因此造成的问题是不可重复读(读事务第一次读取数据结束后释放共享锁,此时其他事务可以更新数据,该事务第二次读取数据时发现与第一次数据值不同)
3.
可重复读(REPEATABLE READ) Mysql默认
在可重复读中,该sql第一次读取到数据后,就将这些数据加锁(悲观锁),其它事务无法修改这些数据,就可以实现可重复读了。
但这种方法却无法锁住insert的数据,所以当事务A先前读取了数据,或者修改了全部数据,事务B还是可以insert数据提交,这时事务A就会发现莫名其妙多了一条之前没有的数据,如果本事务里要插入的数据和这条多出来的数据重复就会触发主键冲突的问题. 这就是幻读,不能通过行锁来避免。需要Serializable隔离级别 .
可重复读隔离级别解决了上面不可重复读的问题(看名字也知道),但是仍然有一个新问题,就是幻读
当你读取id> 10 的数据行时,对涉及到的所有行加上了读锁,此时例外一个事务新插入了一条id=11的数据,因为是新插入的,所以不会触发上面的锁的排斥
那么进行本事务进行下一次的查询时会发现有一条id=11的数据,而上次的查询操作并没有获取到,再进行插入就会有主键冲突的问题.
4.
可串行化(SERIALIZABLE)
使用表级共享锁
这是最高的隔离级别,可以解决上面提到的所有问题,因为他强制将所以的操作串行执行,这会导致并发性能极速下降,因此也不是很常用.

锁的类别
排它锁/写锁(Exclusive Locks,即X锁)
当数据对象被加上排它锁时,其他的事务不能对它读取和修改。
共享锁/读锁(Share Locks,即S锁)
加了共享锁的数据对象可以被其他事务读取,但不能修改。
锁的粒度
锁的粒度取决于具体的存储引擎,InnoDB实现了行级锁,页级锁,表级锁.


mysql 默认自动commit,oracle 默认手动提交

事务控制语句
SET AUTOCOMMIT {ON | OFF | IMMEDIATE | n}    IMMEDIATE选项的功能与ON相同    n表示当Oracle数据库成功执行了n条insert,update,delete或PL/SQL程序块时自动提交事务
Commit; 语句用于提交事务
Rollback; 语句可以将事务回滚到事务的起点或某个保存点开始
Savepoint <回滚点>;     在事务中建立一个存储的点。
Rollback to <回滚点>;

MySQL
mysql的默认的事务处理级别是可重复读
3.
查看当前会话隔离级别
select @@tx_isolation;
JDBC
connection类的commit方法。


丢失更新
第一类 : 事务A撤销时,把已经提交的事务B的更新数据覆盖了.

第二类 : 事务A覆盖事务B已经提交的数据,造成事务B所做的操作丢失.
0

评论区