MySQL锁

1.概述

在数据库中，除传统的计算资源（如CPU、RAM、I/O等）的争用以外，数据也是一种供许多用户共享的资源。为保证数据的一致性，需要对== 并发操作进行控制== ，因此产生了 锁 。同时 锁机制 也为实现MySQL的各个隔离级别提供了保证。 锁冲突 也是影响数据库 并发访问性能 的一个重要因素。所以锁对数据库而言显得尤其重要，也更加复杂。

2.MySQL并发事务访问相同记录

并发事务访问相同记录的情况可以大致分为3种：

2.1 读读情况

读-读 情况，即并发事务相继 读取相同的记录 。读取操作本身不会对记录有任何影响，并不会引起什么问题，所以允许这种情况的发生。

2.2 写写情况

写-写 情况，即并发事务相继对相同的记录做出改动。
在这种情况下会发生 脏写 的问题，任何一种隔离级别都不允许这种问题的发生。所以在多个未提交事务相继对一条记录做改动时，需要让它们 排队执行 ，这个排队的过程其实是通过 锁 来实现的。这个所谓的锁其实是一个 内存中的结构 ，在事务执行前本来是没有锁的，也就是说一开始是没有== 锁结构== 和记录进行关联的，如图所示：
当一个事务想对这条记录做改动时，首先会看看内存中有没有与这条记录关联的 锁结构 ，当没有的时候就会在内存中生成一个 锁结构 与之关联。比如，事务 T1 要对这条记录做改动，就需要生成一个 锁结构与之关联
小结几种说法：

• 不加锁

意思就是不需要在内存中生成对应的 锁结构 ，可以直接执行操作。

• 获取锁成功，或者加锁成功

意思就是在内存中生成了对应的 锁结构 ，而且锁结构的 is_waiting 属性为 false ，也就是事务可以继续执行操作。

• 获取锁失败，或者加锁失败，或者没有获取到锁

意思就是在内存中生成了对应的 锁结构 ，不过锁结构的 is_waiting 属性为 true ，也就是事务需要等待，不可以继续执行操作。

2.3 读写情况或写读情况

读-写 或 写-读 ，即一个事务进行读取操作，另一个进行改动操作。这种情况下可能发生== 脏读 、 不可重复读 、 幻读 ==的问题。
各个数据库厂商对 SQL标准 的支持都可能不一样。比如MySQL在 REPEATABLE READ 隔离级别上就已经解决了 幻读 问题。

2.4 并发问题的解决方案

• 方案一：读操作利用多版本并发控制（ MVCC ，之后讲解），写操作进行 加锁 。

普通的SELECT语句在READ COMMITTED和REPEATABLE READ隔离级别下会使用到MVCC读取记录。

• 在 READ COMMITTED隔离级别下，一个事务在执行过程中每次执行SELECT操作时都会生成一个ReadView，ReadView的存在本身就保证了事务不可以读取到未提交的事务所做的更改
  ，也就是避免了脏读现象；
• 在 REPEATABLE READ 隔离级别下，一个事务在执行过程中只有 第一次执行SELECT操作才会生成一个ReadView，之后的SELECT操作都 复用
  这个ReadView，这样也就避免了不可重复读和幻读的问题

• 方案二：读、写操作都采用 加锁 的方式。
• 小结对比发现：
• 采用 MVCC 方式的话， 读-写 操作彼此并不冲突， 性能更高 。
• 采用 加锁 方式的话， 读-写 操作彼此需要 排队执行 ，影响性能。

一般情况下我们当然愿意采用 MVCC 来解决 读-写 操作并发执行的问题，但是业务在某些特殊情况下，要求必须采用 加锁 的方式执行。下面就讲解下MySQL中不同类别的锁。

3.锁的不同角度分类

锁的类图，如下：

3.1 按照操作类型可以分为读锁、写锁

• 读锁 ：也称为 共享锁 、英文用 S 表示。针对同一份数据，多个事务的读操作可以同时进行而不会互相影响，相互不阻塞的。
• 写锁 ：也称为 排他锁 、英文用 X表示。当前写操作没有完成前，它会阻断其他写锁和读锁。这样就能确保在给定的时间里，只有一个事务能执行写入，并防止其他用户读取正在写入的同一资源。

需要注意的是对于 InnoDB 引擎来说，读锁和写锁可以加在表上，也可以加在行上。

3.2 按照粒度分为表锁、行锁和页锁

表锁：
每次操作都锁住整张表。开销小、加锁快；不会出现死锁；锁定力度大，发生锁冲突的概率最高，并发度低；一般用在整表数据迁移的场景
行锁
对表中一行或多行记录进行加锁控制的方式。开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度高。在MySQL中，行锁是基于索引加载的，即行锁是加在索引响应的行上。索引失效时会升级为表锁。

#给locker表中value列添加索引
ALTER TABLE locker ADD index idx_value (value);

BEGIN;
SELECT * FROM locker WHERE value = 2 FOR UPDATE;

value字段添加索引后，这条SQL只会针对value值为2的记录进行加锁，也就是行锁。在事务提交之前，这些行数据将无法被其他事务修改。
页锁
只有BDB存储引擎支持页锁，页锁就是在页的粒度上进行锁定，锁定的数据资源比行锁要多，因为一个页中可以有多个行记录。当我们使用页锁的时候，会出现数据浪费的现象，但这样的浪费最多也就是一个页上的数据行。页锁的开销介于表锁和行锁之间，会出现死锁。锁定粒度介于表锁和行锁之间，并发度一般。

3.3 按照对锁的态度分为乐观锁、悲观锁

从对待锁的态度来看锁的话，可以将锁分成乐观锁和悲观锁，从名字中也可以看出这两种锁是两种看待数据并发的思维方式 。需要注意的是，乐观锁和悲观锁并不是锁，而是锁的 设计思想
悲观锁
悲观锁是一种思想，顾名思义，就是很悲观，对数据被其他事务的修改持保守态度，会通过数据库自身的锁机制来实现，从而保证数据操作的排它性
悲观锁总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会 阻塞 直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁，当其他线程想要访问数据时，都需要阻塞挂起。Java中 synchronized 和 ReentrantLock 等独占锁就是
悲观锁思想的实现。
乐观锁
乐观锁认为对同一数据的并发操作不会总发生，属于小概率事件，不用每次都对数据上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，也就是不采用数据库自身的锁机制，而是通过程序来实现。
在程序上，我们可以采用 版本号机制 或者 CAS机制 实现。乐观锁适用于多读的应用类型，
这样可以提高吞吐量。在Java中 java.util.concurrent.atomic 包下的原子变量类就是使用了乐观锁的一种实现方式：CAS实现的。
两种锁的使用场景
从这两种锁的设计思想中，我们总结一下乐观锁和悲观锁的适用场景：

1. 乐观锁 适合 读操作多 的场景，相对来说写的操作比较少。它的优点在于 程序实现 ， 不存在死锁问题，不过适用场景也会相对乐观，因为它阻止不了除了程序以外的数据库操作。
2. 悲观锁 适合 写操作多 的场景，因为写的操作具有 排它性 。采用悲观锁的方式，可以在数据库层面阻止其他事务对该数据的操作权限，防止 读 - 写 和 写 - 写 的冲突。

思考：

1.为什么表锁不会发生死锁，而行锁、页锁会发生死锁
因为表锁是对整个表级别上加锁，所以不会出现多个事务同时访问同一张表的锁而导致死锁的情况。即使有多个事务同时访问同一张表的写锁，系统会根据锁的请求顺序进行排队处理，避免死锁的发生。
而行锁和页锁是在数据行或者数据页级别上加锁的。因为行锁和页锁的粒度更细，多个事务可以同时操作同一张表的不同行或不同页，这就增加了死锁的可能性。当多个事务按不同的顺序请求行锁或页锁时，就有可能产生死锁。例如，事务A先锁住了行1，然后请求行2的锁；而事务B先锁住了行2，然后请求行1的锁，这样就会产生死锁。