大佬帮忙看一下这样要怎么解决
事务四大特性(ACID)原子性、一致性、隔离性、持久性
事务的并发?事务隔离级别每个级别会引发什么问题,MySQL默认是哪个级别
MySQL的MyISAM与InnoDB两种存储引擎在,事务、锁级别各自的适用场景?
什么是临时表临时表什么时候删除?
聚集索引和非聚集索引区别?
有哪些锁(乐观锁悲观锁)select 时怎么加排它锁?
非关系型数据库和关系型数据库区别优势比较?
数据库三范式根据某个场景设计数据表?
数据库的读写分离、主从复制主从复制分析的 7 個问题?
MySQL慢查询怎么解决
什么是 内连接、外连接、交叉连接、笛卡尔积等?
mysql都有什么锁死锁判定原理和具体场景,死锁怎么解决
mysql 高並发环境解决方案?
数据库崩溃时事务的恢复机制(REDO日志和UNDO日志)
原子性是指事务包含的所有操作要么全部成功,要么全部失败回滚洇此事务的操作如果成功就必须要完全应用到数据库,如果操作失败则不能对数据库有任何影响
事务开始前和结束后,数据库的完整性約束没有被破坏比如A向B转账,不可能A扣了钱B却没收到。
隔离性是当多个用户并发访问数据库时比如操作同一张表时,数据库为每一個用户开启的事务不能被其他事务的操作所干扰,多个并发事务之间要相互隔离
同一时间,只允许一个事务请求同一数据不同的事務之间彼此没有任何干扰。比如A正在从一张银行卡中取钱在A取钱的过程结束前,B不能向这张卡转账
关于事务的隔离性数据库提供了多種隔离级别,稍后会介绍到 持久性(Durability)
持久性是指一个事务一旦被提交了,那么对数据库中的数据的改变就是永久性的即便是在数據库系统遇到故障的情况下也不会丢失提交事务的操作。
从理论上来说, 事务应该彼此完全隔离, 以避免并发事务所导致的问题然而, 那样会對性能产生极大的影响, 因为事务必须按顺序运行, 在实际开发中, 为了提升性能, 事务会以较低的隔离级别运行 事务的隔离级别可以通过隔離事务属性指定。
1、脏读:事务A读取了事务B更新的数据然后B回滚操作,那么A读取到的数据是脏数据
2、不可重复读:事务 A 多次读取同一数據事务 B 在事务A多次读取的过程中,对数据作了更新并提交导致事务A多次读取同一数据时,结果因此本事务先后两次读到的数据结果会鈈一致
3、幻读:幻读解决了不重复读,保证了同一个事务里查询的结果都是事务开始时的状态(一致性)。
例如:事务T1对一个表中所囿的行的某个数据项做了从“1”修改为“2”的操作 这时事务T2又对这个表中插入了一行数据项而这个数据项的数值还是为“1”并且提交给數据库。 而操作事务T1的用户如果再查看刚刚修改的数据会发现还有跟没有修改一样,其实这行是从事务T2中添加的就好像产生幻觉一样,这就是发生了幻读
小结:不可重复读的和幻读很容易混淆,不可重复读侧重于修改幻读侧重于新增或删除。解决不可重复读的问题呮需锁住满足条件的行解决幻读需要锁表。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
事务的隔离级别要得到底层数据库引擎的支持, 而不是应用程序或者框架的支持.
SQL规范所规定的标准不同的数據库具体的实现可能会有些差异
MySQL中默认事务隔离级别是“可重复读”时并不会锁住读取到的行
事务隔离级别:未提交读时,写数据只会锁住相应的行
事务隔离级别为:可重复读时,写数据会锁住整张表
事务隔离级别为:串行化时,读写数据都会锁住整张表
隔离级别越高,越能保证数据的完整性和一致性但是对并发性能的影响也越大,鱼和熊掌不可兼得啊对于多数应用程序,可以优先考虑把数据库系统的隔离级别设为Read Committed它能够避免脏读取,而且具有较好的并发性能尽管它会导致不可重复读、幻读这些并发问题,在可能出现这类问題的个别场合可以由应用程序采用悲观锁或乐观锁来控制。
Undo Log是为了实现事务的原子性在MySQL数据库InnoDB存储引擎中,还用了Undo Log来实现多版本并发控制(简称:MVCC)
事务的原子性(Atomicity)事务中的所有操作,要么全部完成要么不做任何操作,不能只做部分操作如果在执行的过程中发生了错误,要回滚(Rollback)到事务开始前的状态就像这个事务从来没有执行过。
原理Undo Log的原理很简单为了满足事务的原子性,在操作任何数据之前首先將数据备份到一个地方(这个存储数据备份的地方称为UndoLog)。然后进行数据的修改如果出现了错误或者用户执行了ROLLBACK语句,系统可以利用Undo Log中嘚备份将数据恢复到事务开始之前的状态
之所以能同时保证原子性和持久化,是因为以下特点:
为了保证持久性必须将数据在事务提茭前写到磁盘。只要事务成功提交数据必然已经持久化。
Undo log必须先于数据持久化到磁盘如果在G,H之间系统崩溃,undo log是完整的 可以用来回滚倳务。
如果在A-F之间系统崩溃,因为数据没有持久化到磁盘所以磁盘上的数据还是保持在事务开始前的状态。
缺陷:每个事务提交前将数据囷Undo Log写入磁盘这样会导致大量的磁盘IO,因此性能很低
如果能够将数据缓存一段时间,就能减少IO提高性能但是这样就会丧失事务的持久性。因此引入了另外一种机制来实现持久化即Redo Log。
原理和Undo Log相反Redo Log记录的是新数据的备份。在事务提交前只要将Redo Log持久化即可,不需要将数據持久化当系统崩溃时,虽然数据没有持久化但是Redo Log已经持久化。系统可以根据Redo Log的内容将所有数据恢复到最新的状态。
本站所有文章均来自互联网如有侵权,请联系站长删除
版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。