【MySQL】之锁机制

ゞ浴缸里的玫瑰 2022-12-07 12:25 183阅读 0赞

## 一、锁的概述 ##

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

### 锁的定义 ###

锁是计算机协调多个进程或线程并发访问某一资源的机制。

在数据库中，除传统的计算资源（如CPU、RAM、I/O等）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂。

### 锁的应用实例 ###

我们到淘宝上买一件商品，商品只有一件库存，这个时候如果还有另一个人买，那么如何解决是你买到还是另一个人买到的问题？

这里肯定要用到事务，我们先从库存表中取出物品数量，然后插入订单，付款后插入付款表信息，然后更新商品数量。在这个过程中，使用锁可以对有限的资源进行保护，解决隔离和并发的矛盾。

### 锁定分类 ###

从对数据操作的类型划分：

*  读锁(共享锁)：针对同一份数据，多个读操作可以同时进行而不会互相影响。
 *  写锁（排它锁）：当前写操作没有完成前，它会阻断其他写锁和读锁。

从对数据操作的粒度分：

*  表锁
 *  行锁

为了尽可能提高数据库的并发度，每次锁定的数据范围越小越好，理论上每次只锁定当前操作的数据的方案会得到最大的并发度，但是管理锁是很耗资源的事情（涉及获取，检查，释放锁等动作），因此数据库系统需要在高并发响应和系统性能两方面进行平衡，这样就产生了"锁粒度（Lock granularity）"的概念。

一种提高共享资源并发发性的方式是让锁定对象更有选择性。尽量只锁定需要修改的部分数据，而不是所有的资源。更理想的方式是，只对会修改的数据片进行精确的锁定。任何时候，在给定的资源上，锁定的数据量越少，则系统的并发程度越高，只要相互之间不发生冲突即可。

## 二、MySQL 三锁 ##

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

### 表锁（偏读） ###

表锁偏向MyISAM存储引擎，开销小，加锁快，无死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。

表锁的相关 SQL 语句如下：

*  手动增加表锁：
    
        mysql> lock table tableName1 read(write), tableName2 read(write);
 *  查看表上加过的锁：
    
        mysql> show open tables;
 *  释放表锁：
    
        mysql> unlock tables;

MyISAM在执行查询语句（SELECT）前，会自动给涉及的所有表加读锁，在执行增删改操作前，会自动给涉及的表加写锁。

MySQL的表级锁有两种模式：

*  表共享读锁（Table Read Lock）
 *  表独占写锁（Table Write Lock）

对MyISAM表进行操作，会有以下情况：

*  对MyISAM表的读操作（加读锁），不会阻塞其他进程对同一表的读请求，但会阻塞对同一表的写请求。只有当读锁释放后，才会执行其它进程的写操作。
 *  对MyISAM表的写操作（加写锁），会阻塞其他进程对同一表的读和写操作，只有当写锁释放后，才会执行其它进程的读写操作。

**简而言之，就是读锁会阻塞写，但是不会堵塞读，而写锁则会把读和写都堵塞。**

表锁分析：

可以通过检查 table\_locks\_waited 和 table\_locks\_immediate 状态变量来分析系统上的表锁定：

mysql> show status like 'table%';
    +-----------------------+-------+
    | Variable_name         | Value |
    +-----------------------+-------+
    | table_locks_immediate | 15    |
    | table_locks_waited    | 1     |
    +-----------------------+-------+

这两个状态变量记录MySQL内部表级锁定的情况，两个变量说明如下：

*  Table\_locks\_immediate：产生表级锁定的次数，表示可以立即获取锁的查询次数，每立即获取锁值加1 ；
 *  Table\_locks\_waited：出现表级锁定争用而发生等待的次数(不能立即获取锁的次数，每等待一次锁值加1)，此值高则说明存在着较严重的表级锁争用情况；

此外，MyISAM 的读写锁调度是写优先，这也是 MyISAM 不适合做写为主表的引擎。因为写锁后，其他线程不能做任何操作，大量的更新会使查询很难得到锁，从而造成永远阻塞。

### 行锁（偏写） ###

#### 1、行锁简介 ####

行锁偏向 InnoDB 存储引擎，开销大，加锁慢，会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。

InnoDB 与 MyISAM 的最大不同有两点：一是支持事务（TRANSACTION）；二是采用了行级锁。

测试行锁的方法很简单，只需开两个 Session 会话连接 MySQL，并且两个会话都设置不自动提交：

mysql> set autocommit=0;

当 Session\_1 执行更新某一行数据的操作命令，但没有手动 commit 时，Session\_2 如果执行更新同一行数据时就会被阻塞，只有 Session\_1 执行了 commit 命令之后，Session\_2 才会接触阻塞，从而正常更新。

**注意**：正常情况，各自锁定各自的行，互相不影响，但如果修改的字段上面建了索引，却没有正常使用，可能会导致行锁变表锁，比如没加单引号导致索引失效，行锁变表锁。

#### 2、间隙锁及其危害 ####

**什么是间隙锁？**

当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB 会给符合条件的已有数据记录的索引项加锁；对于键值在条件范围内但并不存在的记录，叫做“间隙（GAP)”，InnoDB 也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁（Next-Key锁）。

**危害**

因为Query执行过程中通过过范围查找的话，他会锁定整个范围内所有的索引键值，即使这个键值并不存在。

间隙锁有一个比较致命的弱点，就是当锁定一个范围键值之后，即使某些不存在的键值也会被无辜的锁定，而造成在锁定的时候无法插入锁定键值范围内的任何数据。在某些场景下这可能会对性能造成很大的危害。

#### 3、行锁的优缺点 ####

Innodb存储引擎由于实现了行级锁定，虽然在锁定机制的实现方面所带来的性能损耗可能比表级锁定会要更高一些，但是在整体并发处理能力方面要远远优于MyISAM的表级锁定的。当系统并发量较高的时候，Innodb的整体性能和MyISAM相比就会有比较明显的优势了。

但是，Innodb的行级锁定同样也有其脆弱的一面，当我们使用不当的时候，可能会让Innodb的整体性能表现不仅不能比MyISAM高，甚至可能会更差。

#### 4、行锁的分析 ####

通过检查 InnoDB\_row\_lock 状态变量来分析系统上的行锁的争夺情况：

mysql>show status like 'innodb_row_lock%';
    +-------------------------------+-------+
    | Variable_name                 | Value |
    +-------------------------------+-------+
    | Innodb_row_lock_current_waits | 0     |
    | Innodb_row_lock_time          | 0     |
    | Innodb_row_lock_time_avg      | 0     |
    | Innodb_row_lock_time_max      | 0     |
    | Innodb_row_lock_waits         | 0     |
    +-------------------------------+-------+

对各个状态量的说明如下：

*  Innodb\_row\_lock\_current\_waits：当前正在等待锁定的数量；
 *  Innodb\_row\_lock\_time：从系统启动到现在锁定总时间长度；
 *  Innodb\_row\_lock\_time\_avg：每次等待所花平均时间；
 *  Innodb\_row\_lock\_time\_max：从系统启动到现在等待最常的一次所花的时间；
 *  Innodb\_row\_lock\_waits：系统启动后到现在总共等待的次数；

对于这5个状态变量，比较重要的主要是 Innodb\_row\_lock\_time\_avg（等待平均时长）、 Innodb\_row\_lock\_waits（等待总次数）、 Innodb\_row\_lock\_time（等待总时长）这三项。尤其是当等待次数很高，而且每次等待时长也不小的时候，我们就需要分析系统中为什么会有如此多的等待，然后根据分析结果着手指定优化计划。

#### 5、行锁优化建议 ####

*  尽可能让所有数据检索都通过索引来完成，避免无索引行锁升级为表锁。
 *  合理设计索引，尽量缩小锁的范围
 *  尽可能较少检索条件，避免间隙锁
 *  尽量控制事务大小，减少锁定资源量和时间长度
 *  尽可能低级别事务隔离

### 页锁 ###

开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。