MySqL 事务与锁的深入学习笔记

秒速五厘米 2022-07-13 03:25 215阅读 0赞

之前学习MySql的简单使用的时候.学习了事务的概念，事务的隔离级别，以及何时使用事务，怎么使用事务等等比较简单的东西。最近不停的在想数据库内部是如何实时事务的，如何避免脏数据的。数据库内部是否有与并发编程中的相似的锁概率呢。Google查阅了相关资料后，记录一下学习笔记。

#### mysql的锁的概述 ####

锁的概率：某个链接对某个资源(可以是一张表，也有可能是一行或者多行记录)进行加锁操作，根据锁的不同功能，决定在加锁期间,其他链接是否允许对该资源有相应的处理权限。  
　　  
　　那么mysql究竟有哪几种类锁呢？

> 一、按操作划分，可分为DML锁、DDL锁
> 
> 二、按锁的粒度划分，可分为表级锁、行级锁、页级锁（mysql BDB支持）
> 
> 三、按锁级别划分，可分为共享锁、排他锁
> 
> 四、按加锁方式划分，可分为自动锁、显示锁
> 
> 五、按使用方式划分，可分为乐观锁、悲观锁

DML锁（data locks，数据锁），用于保护数据的完整性，其中包括行级锁(Row Locks (TX锁))、表级锁(table lock(TM锁))。 DDL锁（dictionary locks，数据字典锁），用于保护数据库对象的结构，如表、索引等的结构定义。其中包排他DDL锁（Exclusive DDL lock）、共享DDL锁（Share DDL lock）、可中断解析锁（Breakable parse locks）

**共享锁**  
　　共享锁就是只针对update时候加锁，在未对update操作提交之前，其他事务只能够获取最新的记录但不能够update操作。  
　　举个例子说吧，假如说事务A读到一条记录，并且修改了该条记录的一个字段的值a改成了b，正在这个时候事务B也读到了这条记录并且获取的A事务修改后的字段值b，事务B想把该字段的值改为c，在此时事务A的修改操作并未提交。那对不起了事务B，因为是事务A先对该记录加锁的，你此时还没有对该条记录上锁的权限哦，不要急哦，等事务A提交之后你就可以改了。

**排他锁**  
一开始就对记录上锁了，在本事务未提交之前别的事务无权进行任何操作。  
还是用上个例子吧，事务A查到一个记录，并修改了其中的一个字段a的值为b，这个时候事务B来获取这条记录，我靠，怎么获取不到呢？原来是排他锁在作怪，这是什么情况。原来排他锁在获取记录的时候就对这条记录上了锁，而且别的事务连获取这条记录的权限都没有，更别提要修改了，必须等到事务A提交了事务释放了锁之后别的事务才能够获取到这条记录。

这两种锁各有利弊，具体使用要看你项目的具体业务的。

>  *  假如你的项目对并发很高对效率要求很高，那么你该选用共享锁，因为在别的事务对某些记录上锁后在事务未提交之前其他事务是有权限去查看的，但是当出现意外导致事务回滚时候，其他事务会多进行一步操作，那就是重新获取这些对象了，不过这比排队等锁要好多了。
>  *  假如你的项目并发数不是很多，同时对整个业务的原子操作要求很高这个时候排他锁是很不错的选择。

#### mysql的锁的级别的区别 ####

mysql究竟能对那些对象上锁呢？现在学习mysql的锁的级别了。  
mysql锁的级别分为三类：页级锁，表级锁，行级锁。  
那有三个级别的锁，mysql究竟用的是哪个级别的呢？这个还得看你用的是什么mysql的引擎了  
mysql大概有下面几个数据库引擎和对应的锁级别

>  *  MyISAM引擎：使用的是表级锁。理解为锁住整个表，可以同时读，写不行。
>  *  MEMORY/heap：使用的是表级锁。理解为锁住整个表，可以同时读，写不行。
>  *  BDB：使用的是页级锁，它也支持表级锁。一次锁定相邻的一组记录。
>  *  InnoDB：使用的是行级锁，它也支持表级锁。单独的一行记录加锁 。

三种锁的特性可大致归纳如下：

>  *  1） 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。分为表共享读锁（共享锁）与表独占写锁（排他锁）。
>  *  2） 行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。 行级锁分为共享锁 和 排他锁。
>  *  3） 页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。  
>     这里我们主要讨论InnoDB存储引擎，也谈论的是行级锁，一般的在秒杀系统中我们会对商品库存使用行级锁，因为秒杀的时候库存是一个很重要的数据，我们在创建数据库的表时可能会出现下面这样的设置：

ENGINE = InnoDB AUTO_INCREMENT=10 DEFAULT CHARACTER SET = utf8 comment='用户表'

将引擎设置为InnoDB，InnnoDB与其他引擎的不同：一是支持事务（TRANCSACTION），二是采用了行级锁。

#### InnoDB中两种模式的行级锁：(也就是最开始讨论的那种锁) ####

>  *  1）共享锁：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。  
>     ( Select \* from table\_name where ……lock in share mode)
>  *  2）排他锁：允许获得排他锁的事务更新数据，阻止其他事务取得相同数据集的共享读锁和 排他写锁。(select \* from table\_name where…..for update)

为了允许行锁和表锁共存，实现多粒度锁机制；同时还有两种内部使用的意向锁（都是表锁），分别为意向共享锁和意向排他锁。意向锁是表级锁，其设计目的主要是为了在一个事务中揭示下一行将要被请求锁的类型。

>  *  意向共享锁（IS）：事务打算给数据行加行共享锁，事务在给一个数据行加共享锁前必须先取得该表的IS锁。
>  *  意向排他锁（IX）：事务打算给数据行加行排他锁，事务在给一个数据行加排他锁前必须先取得该表的IX锁。

**意向锁是InnoDB自动加的，不需要用户干预。**

对于insert、update、delete，InnoDB会自动给涉及的数据加排他锁（X）；对于一般的Select语句，InnoDB不会加任何锁，事务可以通过以下语句给显示加共享锁或排他锁。

共享锁：SELECT … LOCK IN SHARE MODE;

排他锁：SELECT … FOR UPDATE;

注意：InnoDB行锁是通过给索引上的索引项加锁来实现的，这一点与Oracle不同，后者是通过在数据块中对相应数据行加锁来实现的。InnoDB这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！MySQL的行锁是针对索引加的锁，不是针对记录加的锁，所以虽然是访问不同行的记录，但是如果是使用相同的索引键，是会出现锁冲突的。应用设计的时候要注意这一点。

在实际应用中，要特别注意InnoDB行锁的这一特性，不然的话，可能导致大量的锁冲突，从而影响并发性能。

>  *  在不通过索引条件查询的时候,InnoDB 确实使用的是表锁,而不是行锁。
>  *  由于 MySQL 的行锁是针对索引加的锁,不是针对记录加的锁,所以虽然是访问不同行 的记录,但是如果是使用相同的索引键,是会出现锁冲突的。应用设计的时候要注意这一点。
>  *  当表有多个索引的时候,不同的事务可以使用不同的索引锁定不同的行,另外,不论 是使用主键索引、唯一索引或普通索引,InnoDB 都会使用行锁来对数据加锁。
>  *  即便在条件中使用了索引字段,但是否使用索引来检索数据是由 MySQL 通过判断不同 执行计划的代价来决定的,如果 MySQL 认为全表扫 效率更高,比如对一些很小的表,它 就不会使用索引,这种情况下 InnoDB 将使用表锁,而不是行锁。因此,在分析锁冲突时, 别忘了检查 SQL 的执行计划,以确认是否真正使用了索引。

#### 行级锁的优缺点 ####

行级锁定的优点：

>  *  当在许多线程中访问不同的行时只存在少量锁定冲突。
>  *  回滚时只有少量的更改。
>  *  可以长时间锁定单一的行。

行级锁定的缺点：

>  *  比页级或表级锁定占用更多的内存。
>  *  当在表的大部分数据上使用时，比页级或表级锁定速度慢，因为你必须获取更多的锁。如果你在大部分数据上经常进行GROUP BY操作或者必须经常扫描整个表，比其它锁定明显慢很多。

**行级锁的死锁**

MyISAM中是不会产生死锁的，因为MyISAM总是一次性获得所需的全部锁，要么全部满足，要么全部等待。而在InnoDB中，锁是逐步获得的，就造成了死锁的可能。

**在MySQL中，行级锁并不是直接锁记录，而是锁索引。索引分为主键索引和非主键索引两种，如果一条sql语句操作了主键索引，MySQL就会锁定这条主键索引；如果一条语句操作了非主键索引，MySQL会先锁定该非主键索引，再锁定相关的主键索引.**在UPDATE、DELETE操作时，MySQL不仅锁定WHERE条件扫描过的所有索引记录，而且会锁定相邻的键值，即所谓的next-key locking。

当两个事务同时执行，一个锁住了主键索引，在等待其他相关索引。另一个锁定了非主键索引，在等待主键索引。这样就会发生死锁。

发生死锁后，InnoDB一般都可以检测到，并使一个事务释放锁回退，另一个获取锁完成事务。

有多种方法可以避免死锁，这里只介绍常见的三种

>  *  1、如果不同程序会并发存取多个表，尽量约定以相同的顺序访问表，可以大大降低死锁机会。
>  *  2、在同一个事务中，尽可能做到一次锁定所需要的所有资源，减少死锁产生概率；
>  *  3、对于非常容易产生死锁的业务部分，可以尝试使用升级锁定颗粒度，通过表级锁定来减少死锁产生的概率；

#### 悲观锁与乐观锁 ####

之前说过数据库管理系统（DBMS）中的并发控制的任务是确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的统一性。

乐观并发控制(乐观锁)和悲观并发控制（悲观锁）是并发控制主要采用的技术手段。

无论是悲观锁还是乐观锁，都是人们定义出来的概念，可以认为是一种思想。其实不仅仅是关系型数据库系统中有乐观锁和悲观锁的概念，像memcache、hibernate、tair等都有类似的概念。

针对于不同的业务场景，应该选用不同的并发控制方式。所以，不要把乐观并发控制和悲观并发控制狭义的理解为DBMS中的概念，更不要把他们和数据中提供的锁机制（行锁、表锁、排他锁、共享锁）混为一谈。其实，在DBMS中，悲观锁正是利用数据库本身提供的锁机制来实现的。

下面具体来学习一下悲观锁和乐观锁:

**悲观锁**  
在关系数据库管理系统里，悲观并发控制（又名“悲观锁”，Pessimistic Concurrency Control，缩写“PCC”）是一种并发控制的方法。它可以阻止一个事务以影响其他用户的方式来修改数据。如果一个事务执行的操作都某行数据应用了锁，那只有当这个事务把锁释放，其他事务才能够执行与该锁冲突的操作。  
悲观并发控制主要用于数据争用激烈的环境，以及发生并发冲突时使用锁保护数据的成本要低于回滚事务的成本的环境中。  
悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度(悲观)，因此，在整个数据处理过程中，将数据处于锁定状态。 悲观锁的实现，往往依靠数据库提供的锁机制 （也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）

在数据库中，悲观锁的流程如下：

在对任意记录进行修改前，先尝试为该记录加上排他锁（exclusive locking）。

如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。 具体响应方式由开发者根据实际需要决定。

如果成功加锁，那么就可以对记录做修改，事务完成后就会解锁了。

其间如果有其他对该记录做修改或加排他锁的操作，都会等待我们解锁或直接抛出异常。

MySQL InnoDB中使用悲观锁

要使用悲观锁，我们必须关闭mysql数据库的自动提交属性，因为MySQL默认使用autocommit模式，也就是说，当你执行一个更新操作后，MySQL会立刻将结果进行提交。set autocommit=0;

//0.开始事务
    begin;/begin work;/start transaction; (三者选一就可以)
    //1.查询出商品信息
    select status from t_goods where id=1 for update;
    //2.根据商品信息生成订单
    insert into t_orders (id,goods_id) values (null,1);
    //3.修改商品status为2
    update t_goods set status=2;
    //4.提交事务
    commit;/commit work;

上面的查询语句中，我们使用了select…for update的方式，这样就通过开启排他锁的方式实现了悲观锁。此时在t\_goods表中，id为1的 那条数据就被我们锁定了，其它的事务必须等本次事务提交之后才能执行。这样我们可以保证当前的数据不会被其它事务修改。

上面我们提到，使用select…for update会把数据给锁住，不过我们需要注意一些锁的级别，MySQL InnoDB默认行级锁。行级锁都是基于索引的，如果一条SQL语句用不到索引是不会使用行级锁的，会使用表级锁把整张表锁住，这点需要注意。

优点与不足

悲观并发控制实际上是“先取锁再访问”的保守策略，为数据处理的安全提供了保证。但是在效率方面，处理加锁的机制会让数据库产生额外的开销，还有增加产生死锁的机会；另外，在只读型事务处理中由于不会产生冲突，也没必要使用锁，这样做只能增加系统负载；还有会降低了并行性，一个事务如果锁定了某行数据，其他事务就必须等待该事务处理完才可以处理那行数

**乐观锁**

在关系数据库管理系统里，乐观并发控制（又名“乐观锁”，Optimistic Concurrency Control，缩写“OCC”）是一种并发控制的方法。它假设多用户并发的事务在处理时不会彼此互相影响，各事务能够在不产生锁的情况下处理各自影响的那部分数据。在提交数据更新之前，每个事务会先检查在该事务读取数据后，有没有其他事务又修改了该数据。如果其他事务有更新的话，正在提交的事务会进行回滚。乐观事务控制最早是由孔祥重（H.T.Kung）教授提出。  
乐观锁（ Optimistic Locking ） 相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。

相对于悲观锁，在对数据库进行处理的时候，乐观锁并不会使用数据库提供的锁机制。一般的实现乐观锁的方式就是记录数据版本。

数据版本,为数据增加的一个版本标识。当读取数据时，将版本标识的值一同读出，数据每更新一次，同时对版本标识进行更新。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的版本标识进行比对，如果数据库表当前版本号与第一次取出来的版本标识值相等，则予以更新，否则认为是过期数据。  
实现数据版本有两种方式，第一种是使用版本号，第二种是使用时间戳。

使用版本号实现乐观锁

使用版本号时，可以在数据初始化时指定一个版本号，每次对数据的更新操作都对版本号执行+1操作。并判断当前版本号是不是该数据的最新的版本号。

1.查询出商品信息
    select (status,status,version) from t_goods where id=#{id}
    2.根据商品信息生成订单
    3.修改商品status为2
    update t_goods 
    set status=2,version=version+1
    where id=#{id} and version=#{version};

优点与不足

乐观并发控制相信事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。但如果直接简单这么做，还是有可能会遇到不可预期的结果，例如两个事务都读取了数据库的某一行，经过修改以后写回数据库，这时就遇到了问题。

#### sql语句分析背后的锁实现(基于InnoDB存储引擎) ####

MySQL InnoDB存储引擎，实现的是基于多版本的并发控制协议——MVCC (Multi-Version Concurrency Control) (注：与MVCC相对的，是基于锁的并发控制，Lock-Based Concurrency Control)。MVCC最大的好处，相信也是耳熟能详：读不加锁，读写不冲突。在读多写少的应用中，读写不冲突是非常重要的，极大的增加了系统的并发性能，这也是为什么现阶段，几乎所有的RDBMS，都支持了MVCC。

在MVCC并发控制中，读操作可以分成两类：快照读 (snapshot read)与当前读 (current read)。快照读，读取的是记录的可见版本 (有可能是历史版本)，不用加锁。当前读，读取的是记录的最新版本，并且，当前读返回的记录，都会加上锁，保证其他事务不会再并发修改这条记录。

在一个支持MVCC并发控制的系统中，哪些读操作是快照读？哪些操作又是当前读呢？以MySQL InnoDB为例：

快照读：简单的select操作，属于快照读，不加锁。(当然，也有例外，下面会分析)

select * from table where ?;

当前读：特殊的读操作，插入/更新/删除操作，属于当前读，需要加锁。

select * from table where ? lock in share mode;
    select * from table where ? for update;
    insert into table values (…);
    update table set ? where ?;
    delete from table where ?;

所有以上的语句，都属于当前读，读取记录的最新版本。并且，读取之后，还需要保证其他并发事务不能修改当前记录，对读取记录加锁。其中，除了第一条语句，对读取记录加S锁 (共享锁)外，其他的操作，都加的是X锁 (排它锁)。

**为什么将 插入/更新/删除 操作，都归为当前读？可以看看下面这个 更新 操作，在数据库中的执行流程：**

![这里写图片描述][SouthEast]

从图中，可以看到，一个Update操作的具体流程。当Update SQL被发给MySQL后，MySQL Server会根据where条件，读取第一条满足条件的记录，然后InnoDB引擎会将第一条记录返回，并加锁 (current read)。待MySQL Server收到这条加锁的记录之后，会再发起一个Update请求，更新这条记录。一条记录操作完成，再读取下一条记录，直至没有满足条件的记录为止。因此，Update操作内部，就包含了一个当前读。同理，Delete操作也一样。Insert操作会稍微有些不同，简单来说，就是Insert操作可能会触发Unique Key的冲突检查，也会进行一个当前读，读取这个主键是否已经存在。

注：根据上图的交互，针对一条当前读的SQL语句，InnoDB与MySQL Server的交互，是一条一条进行的，因此，加锁也是一条一条进行的。先对一条满足条件的记录加锁，返回给MySQL Server，做一些DML操作；然后在读取下一条加锁，直至读取完毕。

传统RDBMS加锁的一个原则，就是2PL (二阶段锁)：Two-Phase Locking。相对而言，2PL比较容易理解，说的是锁操作分为两个阶段：加锁阶段与解锁阶段，并且保证加锁阶段与解锁阶段不相交。下面，仍旧以MySQL为例，来简单看看2PL在MySQL中的实现。

![这里写图片描述][SouthEast 1]

从上图可以看出，2PL就是将加锁/解锁分为两个完全不相交的阶段。加锁阶段：只加锁，不放锁。解锁阶段：只放锁，不加锁。

hibernate中通过行级锁实现的悲观锁。

一些例子：

假设有个表单products ，里面有id跟name二个栏位，id是主键。  
1: 明确指定主键，并且有此条记录，执行row lock。若查无此记录，无lock。

SELECT * FROM products WHERE id='3' FOR UPDATE;
    SELECT * FROM products WHERE id='3' and name="cat" FOR UPDATE;

2: 无主键，执行table lock。

SELECT * FROM products WHERE name='Mouse' FOR UPDATE;

3: 主键不明确，table lock。

SELECT * FROM products WHERE id<>'3' FOR UPDATE;

注意： FOR UPDATE仅适用于InnoDB，且必须在事务块(BEGIN/COMMIT)中才能生效。此外，如果A与B都对表id进行查询但查询不到记录，则A与B在查询上不会进行row锁，但A与B都会获取排它锁，此时A再插入一条记录的话则会因为B已经有锁而处于等待中，此时B再插入一条同样的数据则会抛出Deadlock found when trying to get lock; try restarting transaction然后释放锁，此时A就获得了锁而插入成功。

#### Mysql事务与隔离级别 ####

事务就是一段sql 语句的批处理，但是这个批处理是一个atom（原子） ，不可分割，要么都执行，要么回滚（rollback）都不执行。只有InnoDB引擎的数据库transaction\_safe table 才能支持事务。事务的使用比较简单,这里介绍事务的四种隔离级别:

MySQL/InnoDB定义的4种隔离级别：

> Read Uncommited  
> 这种隔离级别可以让当前事务读取到其它事物还没有提交的数据。这种读取应该是在回滚段中完成的。这种隔离级别是最低的
> 
> Read Committed (RC)  
> 这种隔离级别可以让当前事务读取到其它事物已经提交的数据。这种隔离级别会导致引发不可重复读，和幻读。
> 
> Repeatable Read (RR)  
> 这种隔离级别可以保证在一个事物中多次读取特定记录的时候都是一样的。这种隔离级别会导致引发幻读。
> 
> Serializable  
> 这种隔离级别将事物放在一个队列中，每个事物开始之后，别的事物被挂起。同一个时间点只能有一个事物能操作数据库对象。这种隔离级别对于数据的完整性是最高的，但是同时大大降低了系统的可并发性。

**Serializable隔离级别下，采用的是单线程来解决并发访问的问题，也就是说在某一段时间内，只能有一个用户对数据库进行操作，导致其它用户阻塞。导致数据库的访问性能很差。并发度急剧下降，在MySQL/InnoDB下不建议使用。**

#### 数据库隔离级别的应用: ####

在分布式的系统中，通常会有多个线程连接到数据库中同时对一个表进行操作(这里的同时并不表示同一个时间点，而是同时竞争cpu的资源，至于如何调度，就要看线程和操作系统如何进行调度了)，这种情况下如果会话的事物设置不当，就会导致数据混乱，常常会出现以下三种情况(假设现在系统中有两个会话A和B，同时对表T\_Test操作)：

**脏读**  
如果有A向B 做了这个操作：

update account set money=money+100 where name='B';

在没有commit 之前B 查询：

select money from account where name='B';

找到了没有提交的money ，之后A在此时有rollback ，B 再查询，100 不见了。为了避免则提高数据库的隔离级别：read committed 。就是只能读取提交后的数据。

**不可重复读**  
上述示例中说明的就是我们不能读取一个事务的中间状态。 而重复读是指我们每次读取到的结果都要一直。 这个也是mysql 默认的级别。

**虚读**  
在一个事务内读取到了别的事务插入的数据，导致前后读取不一致。和不可重复读的区别是：不可重复读是读取到了别人对表中的某一条记录进行了修改，导致前后读取的数据不一致。 虚读是前后读取到表中的记录总数不一样，读取到了其它事务插入的数据。比如现在有 A 和 B 两个应用程序，他们并发访问了数据库中的某一张表，假设表中有 3 条记录，B 执行查询操作， 第一次查询表得到了 3 条记录。此时 A 对表进行了修改，增加了一条记录，当 B 再次查询表的时候，发现多了一条数据。这种情况就造成了 B 的虚读。但是虚读是不一定每次都发生的，这种情况是不确定的。为了避免虚读，我们可以将事物隔离级别设置为 serializable 如果设置成了这种级别，那么数据库就变成了单线程访问的数据库，导致性能降低很多。

一种更易理解的说法是：在一个事务内，多次读同一个数据。在这个事务还没有结束时，另一个事务也访问该同一数据。那么，在第一个事务的两次读数据之间。由于第二个事务的修改，那么第一个事务读到的数据可能不一样，这样就发生了在一个事务内两次读到的数据是不一样的，因此称为不可重复读，即原始读取不可重复。

脏读又称无效数据的读出，是指在数据库访问中，事务T1将某一值修改，然后事务T2读取该值，此后T1因为某种原因撤销对该值的修改，这就导致了T2所读取到的数据是无效的。脏读就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是脏数据，依据脏数据所做的操作可能是不正确的.

summary：

（1）Serializable：可避免脏读、不可重复读、虚读情况的发生。

（2）Repeatable read：可避免脏读、不可重复读情况的发生。（可重复读，是 mysql 默认的事务隔离级别）

（3）Read committed：可避免脏读情况发生。（读取已提交的数据）

（4）Read uncommitted：最低级别，以上情况均无法保证。（读取到了未提交的数据）

**这四种隔离级别用的技术就是锁，并且除了Read uncommitted，全部忽略了快照读而是当前读。。。**

#### 一条简单SQL的加锁实现分析 ####

在介绍完一些背景知识之后，本文接下来将选择几个有代表性的例子，来详细分析MySQL的加锁处理。当然，还是从最简单的例子说起。分析他们加什么锁？

SQL1：select * from t1 where id = 10;
    SQL2：delete from t1 where id = 10;

针对这个问题，该怎么回答？我能想象到的一个答案是：

SQL1：不加锁。因为MySQL是使用多版本并发控制(MVCC)的，读不加锁。  
SQL2：对id = 10的记录加写锁 (走主键索引)。

[SouthEast]: /images/20220713/a8a6adc13df64a1e915cfe33f8c00da9.png
[SouthEast 1]: /images/20220713/7c1d1da657974247ad9a0c66007ad938.png