MySQL学习笔记（四）—— 事务与并发控制

雨点打透心脏的1/2处 2023-07-20 08:25 49阅读 0赞

## 事务 ##

1.  概念
    
    一个事务可以理解为一组操作，这一组操作要么全部执行，要么全部不执行。
2.  特性
    
    1.  **原子性**
        
        一个事务是一个独立的原子单元，一个事务内所有的操作，要么全部执行，要么全部不执行。关注的是一组操作的执行结果（全部成功or全部失败）。是通过undo log实现的。
    2.  **一致性**
        
        看了网上很多博客对一致性的讲解，总觉得没有说到点子上，我就从我的个人角度来说说对一致性的理解：
        
        一个事务使得数据库从一个状态A0，转换到另一个状态A1。相邻的两个状态转换之间，只能有一个事务起作用。如果当前状态A0转换到下一个状态A1，之间包括了2个事务，则说明有一个事务的effect被覆盖了。如事务并发问题中的丢失更新，典型的例子是转账问题，A向B转账，同时C也向B转账，最后会发现A或者C转过去的钱不见了，这种例子随便一搜就有，不赘述。用转账问题来解释一致性，比较好理解，因为钱的总数应该是确定的，比如B本来有1000，A向B转100，C向B转200，那么B账户上最后应该有1300，然而最终我们可能看到是1100或1200，因为有一个人的操作被覆盖掉了。其实这也就是说，B账户的钱，从一个状态，到另一个状态，中间有2个事务起了effect，这样是不对的。事务具有隔离性，数据库的每一个状态，应该都有且仅有一个与之对应的事务在take effect。
    3.  **隔离性**
        
        不同的事务之间，应该是不能互相影响的。
        
        4种隔离级别
        
        1.  Read Uncommit
        2.  Read Commit
        3.  Repetable Read
        4.  Serializable
        
        RU相当于没有隔离，RC和RR是用MVCC实现（具体是通过undo log 和 read view），Serializable是用锁实现，事务串行执行。
        
        查看当前的隔离级别
        
            select @@tx_isolation;
            -- mysql 8的变量名变为如下的形式
            select @@transaction_isolation;
            
            -- 设置隔离级别
            set transacation_isolation = '隔离级别名'
        
        ![在这里插入图片描述][20200331221414248.png]
        
        数据库隔离级别是一种需求，不同的隔离级别有对应的实现方式。
    4.  **持久性**
        
        事务执行成功后（提交后），对数据库的更改是永久性的（即写到磁盘）。是通过redo log + Force Log at Commit机制实现的
3.  事务并发问题
    
    1.  丢失更新
        
        1.  第一类丢失更新
            
            针对同一行数据，事务A先开始，事务B后开始，事务B提交，随后事务A回滚，则回滚会导致将事务B已提交的修改给覆盖掉。这个问题在现在的数据库软件中已不会产生
        2.  第二类丢失更新
            
            针对同一行数据，事务A先开始，事务B后开始，事务A提交，随后事务B提交，则事务B将事务A的修改给覆盖掉了
    2.  脏读
        
        事务A读到了事务B未提交的数据，事务B后回滚，则事务A读到的是脏数据
    3.  不可重复读
        
        事务A连续2次读一行记录，读取到的是不一样的。这是由于A连续2次读的中间，事务B对这行记录做了更新。
    4.  幻读
        
        表现为两次读取的数据数量不一致，发现变多了，或者变少了。
        
        比如我读取age > 10 的学生数据，第一次读发现有10个学生，第二次读发现有20个学生，就好像出现了幻觉一样，同样的查询条件，两次读取发现有学生增加或减少。
4.  事务命令
    
    MySQL命令行下默认是autocommit的，即事务会自动提交。要显示开启一个事务，需使用命令`BEGIN`或`START TRANSACTION`
    
     *  `BEGIN` 或 `START TRANSACTION` 开启事务
     *  `COMMIT` 提交事务
     *  `ROLLBACK` 回滚事务

## 并发控制 ##

两种并发控制策略

1.  MVCC
    
    Multi-Version Concurrency Control
    
    核心理念是快照，InnoDB主要通过undo log 和 read view来实现MVCC。
    
    \*\*读不加锁，读写不互斥。\*\*读会从多个版本的数据中挑选一个合适的版本返回。写操作会产生一个新的版本。
    
    每一行的记录，会包含3个隐藏字段：row\_id，tx\_id，roll\_ptr
    
    其中tx\_id表示最近操作该行记录的事务id，roll\_ptr则是回滚指针，指向一条undo log记录，即指向该次改动之前的数据  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3ZjajEwMDk3ODQ4MTQ_size_16_color_FFFFFF_t_70]
    
    **undo log**
    
     *  insert undo log
        
        由insert操作产生，可在事务提交后直接删除。因为insert操作只对当前事务本身可见，其他事务不可见
     *  update undo log
        
        由update/delete产生。是对已有记录的修改，为了提供MVCC机制，该undo log不能在事务提交后就删除，而需要等待purge线程来进行最后的删除
        
        使用update修改当前行时，首先用X锁锁定，然后将该行当前值复制到undo log，然后再执行修改，最后填写事务id，并使回滚指针指向undo log中修改前的行  
        ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3ZjajEwMDk3ODQ4MTQ_size_16_color_FFFFFF_t_70 1]
    
    **read view**
    
    用于判断**数据可见性**的一个数据结构，里面存储了
    
     *  当前活跃事务的最小id：min\_id
     *  当前活跃事务的最大id：max\_id
     *  当前活跃事务id list：ids
    
    若读取到的某一行的某个版本tx\_id < min\_id，则说明此行的该版本在本次事务开启之前就已经提交，故这个数据对本次事务可见。
    
    若读取到的某一行的某个版本tx\_id >= max\_id，说明此行的该版本在本次事务开启之后才开始进行修改，故这个数据对本次事务不可见。
    
    若读取到的某一行的某个版本tx\_id在min\_id和max\_id之间，则判断此行的tx\_id是否在ids内，若是，表明此行的事务还在活跃中，此行数据不可见，否则，说明此行的事务已经提交，此行数据可见
    
    简单来说，若在某一时刻开启了一个事务A，则会记录下事务A开启时，还活跃着的其他事务（记下这些活跃事务的id，保存为一个set，比如叫ids），这些事务按照开始的时间先后，会有从小到大的事务id（tx\_id），tx\_id小的事务，说明是先开启的，tx\_id大的事务，说明是后开启的。若在事务A中，读取到某一行数据，这一行数据的tx\_id小于ids中最小的id（min\_id），说明这一行数据对应的事务，已提交过了（已不活跃了），这一行数据的修改已经持久化，故该行数据对事务A来说是可见的。若这一行数据的tx\_id大于或等于ids中的最大id，说明有一个事务，在事务A开始之后，才开始对这一行数据进行修改，故该行数据对事务A不可见。若这一行数据的tx\_id，在min\_id和max\_id之间，那么就判断这个tx\_id是不是在ids中，即对这行数据进行修改的那个事务，还在不在活跃的事务列表中，若在，说明修改这行数据的事务还没提交，这行数据还没持久化，故不可见，反之，说明这行数据的修改已经持久化，故可见。
    
    RC隔离级别下，在一个事务中，每次读取数据都会新建一个ReadView。所以可能会产生不可重复读的问题，因为在两次读之间，有其他事务对数据进行了修改，而两次读时都新建了ReadView，故第二次读的时候，修改后的数据是可见的。
    
    RR隔离级别下，在一个事务中，第一次读取时会新建一个ReadView，后序读取都使用这个ReadView。所以哪怕在两次读之间，有其他事务修改了数据，也不会产生不可重复读的问题。因为第二次读，并没有新建ReadView，而是使用了一开始创建的那个ReadView，所以数据可见性和第一次是一样的。
    
    MVCC中，**读操作分为两类：快照读，当前读**
    
     *  快照读（一致性非锁定读）  
        读取的时记录的可见版本（可能是历史版本），不加锁。  
        当某一行被一个事务A加了X锁时，另一个事务B仍然可以读取该行，只不过读取的是历史版本。
    
        -- 简单select
        SELECT * FROM product;

*  当前读
    
    读取的是记录的最新版本，当前读返回的记录，会加锁，保证了其他并发事务不能修改当前记录
    
        SELECT * FROM product lock in share mode;
        SELECT * FROM product for update;
        insert ....
        update ....
        delete ....

#### LBCC ####

1.  LCC
    
    Lock-Based Concurrency Control
    
    读加读锁，写加写锁。读读不互斥，读写，写写互斥。Serilizable的隔离级别是通过LBCC实现的

[20200331221414248.png]: /images/20230528/6dd96ebf137c47568da194085a9e8ab0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3ZjajEwMDk3ODQ4MTQ_size_16_color_FFFFFF_t_70]: /images/20230528/52e3f83d62874e669c229ccbdc99056f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3ZjajEwMDk3ODQ4MTQ_size_16_color_FFFFFF_t_70 1]: /images/20230528/dd1cac102be544f4bb7de49eb3b83190.png