MySql中的事务,隔离机制以及涉及到的锁总结

素颜马尾好姑娘i 2024-04-18 12:44 4阅读 0赞

# MySql中的事务,隔离机制以及涉及到的锁总结 #

纯手打,希望可以帮助大家, 转载的话附上链接就可以啦. 希望大家多提意见,逐步完善

--------------------

1.  **MySql事务**

事务就是一组SQL要么全部成功执行,要么全都不执行,哪怕其中任何一个SQL出现操作异常执行过的SQL也会进行回滚

事务的性质(**A C I D**)

*  Atomic \*\*原子性:\*\*整个事务是一个原子操作,要么全部成功,要么会回滚到初始状态,just like 整个事务中的sql从未执行过一样
 *  Consistency \*\*一致性:\*\*数据库经过事务以后,整个数据库状态是完美从一个状态到另一个状态,是完全符合规则的.例如 A向B转了一百块,最后的状态是A的账户少了100,B的账号多了100. 这就是一致性
 *  Isolation \*\*隔离性:\*\*数据库允许并行多个事务执行数据的更新,隔离性可以防止多个事务并发交叉执行而导致的数据不一致问题. 事务隔离分为多个级别,包括 未提交(Read uncommitted),读提交(read committed),可重复读(repeatable read)和串行化(Serializable)
 *  Durability \*\*持久性:\*\*一个事务执行完毕,对数据的修改时永久的,及时系统故障也不会丢失

1.  **事务的隔离级别**
    
    <table> 
     <thead> 
      <tr> 
       <th align="right">离级别</th> 
       <th align="center">脏读可能性</th> 
       <th align="center">不可重复读可能性</th> 
       <th align="center">幻读可能性</th> 
       <th align="center">加锁读</th> 
      </tr> 
     </thead> 
     <tbody> 
      <tr> 
       <td align="right">ead Uncommitted</td> 
       <td align="center">Yes</td> 
       <td align="center">Yes</td> 
       <td align="center">Yes</td> 
       <td align="center">N0</td> 
      </tr> 
      <tr> 
       <td align="right">ead Committed</td> 
       <td align="center">No</td> 
       <td align="center">Yes</td> 
       <td align="center">Yes</td> 
       <td align="center">No</td> 
      </tr> 
      <tr> 
       <td align="right">epeatable Read</td> 
       <td align="center">No</td> 
       <td align="center">No</td> 
       <td align="center">Yes</td> 
       <td align="center">No</td> 
      </tr> 
      <tr> 
       <td align="right">erializable</td> 
       <td align="center">No</td> 
       <td align="center">No</td> 
       <td align="center">No</td> 
       <td align="center">Yes</td> 
      </tr> 
     </tbody> 
    </table>
    
    隔离级别是针对在多个事务在并发情况下出现的数据问题例如:**脏读,不可重复读,幻读**采取的不同隔离标准.我们按照数据安全级别由低到高来讲下上边的四个隔离级别:
    
     *  未提交读(Read uncommitted):最低的隔离级别,啥也保证不了,一般不会使用
     *  已提交读(Read committed):解决了脏读的问题,不会读取到其他事物事物未提交所做的新增和更新
     *  可重复读(Repeatable read):解决了脏读,和**不可重复读**,但是会出现幻读. Mysql的InnoDB引擎默认就是该隔离级别
     *  串行化(Serializable):最高级别,但是并发处理能力最低,鱼和熊掌不能兼得
    
    这是四个隔离级别,那么我们讲一下上边出现的数据问题,究竟什么是**脏读?不可重复读?幻读?**
    
     *  脏读:事务A会读取到事务B还没有提交事务之前做的数据更改,事务A此时读到的数据还没有真正持久化到数据库,万一事务B回滚了,那么事务A读到的数据就是’脏’的
     *  不可重复读: 不可重复读面向的重点是update/delete情况下出现的,在一个事务A中假设查询了两次账户余额,由于别的事务更新操作,两次查询到的账户余额是不一样的,此时就说是**不可重复读**
     *  幻读: 幻读主要针对别的数据进行的Insert操作,比如在一个事务A中要插入一条ID为10的数据,并且查询的时候没有ID为10的数据存在,但是插入的时候报错,说ID重复,这就是典型的幻读场景
    
    针对以上可能会因为并发事务导致的问题主要解决方式有如下两种
    
    1.  在读取数据之前,对其加锁,阻止其他事务对其进行修改,那么以上问题都可解决
    2.  另一种是不用加任何锁，通过一定机制生成一个数据请求时间点的一致性数据快照（**Snapshot**)，并用这个快照来提供一定级别（语句级或事务级）的一致性读取。从用户的角度来看，好像是数据库可以提供同一数据的多个版本，因此，这种技术叫做数据**多版本并发控制**（MultiVersion Concurrency Control，简称MVCC或MCC），也经常称为多版本数据库。
2.  **MySQL中的锁**
    
    `MyISAM`引擎的锁只支持**表锁**,还有支持并发条件下的尾部插入,MyISAM也不支持事务,在此不做为重点讲解.
    
    `InnoDB`引擎支持事务,并且不仅支持**表锁**,还支持**行锁**来提高并发下的吞吐量
    
     *  表锁:在操作更新或者读取的时候,将整个表锁住,不允许任何对该表的查找和修改,保证了表数据的正确性,但是导致并发效率很低,很多会话会处于等待状态浪费资源,造成很低的吞吐量
     *  行锁:`InnoDB`实现了两种行锁
        
        1.  共享锁(S):允许多个事务获取该共享锁`Share Lock`,但是大家都不能对该行数据进行修改,要想修改该行数据(要获取该行的排它锁,也就是写锁 必须等待所以共享锁事务释放完毕才可以)
        2.  排它锁(X):一个事务一旦获取数据A的排它锁,其他任何事物都无法获取锁(但是可以进行查询,只是不能获取共享锁,排它锁而已),只能进行等待,排它锁即可读数据又可以写数据
        3.  意向锁:意向锁是表级锁,其设计目的是为了揭示事务中下一行将要被请求锁的类型,InnoDB中的两个表锁
            
            意向共享锁(IS):表示事务准备给数据加共享锁,也就是加共享锁之前首先要获得该表的IS锁
            
            意向排它锁(IX):表示事务准备给数据行加排它锁,说明一个事务在对一行数据加排它锁之前首先必须获得该数据的IX锁
            
            **意向锁是InnoDB自动加的,不需要用户干预**
    
    **锁的总结:**
    
    对于insert、update、delete，InnoDB会自动给涉及的数据加排他锁（X）；对于一般的Select语句，InnoDB不会加任何锁，事务可以通过以下语句给显示加共享锁或排他锁。
    
    共享锁：`SELECT ... LOCK IN SHARE MODE;`
    
    排他锁：`SELECT ... FOR UPDATE;`
3.  **间隙锁(Next-Key锁)**
    
    间隙锁举例: 当前user表中有ID为:1-101条数据
    
    当执行`select * from user where ID>100 for update` 这个范围查找并且获取排它锁
    
    加锁情况: 不仅仅对满足条件且真实存在的ID=101数据加锁, 对不存在数据库中的饭为 ID>101 这个很大的`间隙`加锁, 也就是其他尝试插入的SQL会阻塞等待
4.  深入了解行锁:
    
    1.  在InnoDB当中,行锁是锁在对应的索引上,此处应该注意**只有通过索引查找的数据才会使用行锁,否则将使用表锁,需要注意这点,非常影响效率**
    2.  虽然不是相同的行,如果使用的是相同的索引,则获取锁的两行的时候会冲突,因为索引相同,则锁两个行锁资源一样.
    3.  即便在条件中使用了索引字段，但是否使用索引来检索数据是由MySQL通过判断不同执行计划的代价来决定的，如果MySQL认为全表扫描效率更高，比如对一些很小的表，它就不会使用索引，这种情况下InnoDB将使用表锁，而不是行锁。因此，在分析锁冲突时，别忘了检查SQL的执行计划，以确认是否真正使用了索引。