【学习笔记】Mysql中锁定机制介绍及优化建议

 

【注】：本文内容来自简朝阳编写的《mysql性能调优与架构设计》中学习摘录

一、Mysql中锁定机制介绍

MySQL 各存储引擎使用了三种类型（级别）的锁定机制：行级锁定，页级锁定和表级锁定。下面我们先分析一下MySQL 这三种锁定的特点和各自的优劣所在。

● 行级锁定（row-level）

行级锁定最大的特点就是锁定对象的颗粒度很小，也是目前各大数据库管理软件所实现的锁定颗粒度最小的。由于锁定颗粒度很小，所以发生锁定资源争用的概率也最小，能够给予应用程序尽可能大的并发处理能力而提高一些需要高并发应用系统的整体性能。

虽然能够在并发处理能力上面有较大的优势，但是行级锁定也因此带来了不少弊端。由于锁定资源的颗粒度很小，所以每次获取锁和释放锁需要做的事情也更多，带来的消耗自然也就更大了。此外，行级锁定也最容易发生死锁。

● 表级锁定（table-level）

和行级锁定相反，表级别的锁定是MySQL各存储引擎中最大颗粒度的锁定机制。该锁定机制最大的特点是实现逻辑非常简单，带来的系统负面影响最小。所以获取锁和释放锁的速度很快。由于表级锁一次会将整个表锁定，所以可以很好的避免困扰我们的死锁问题。

当然，锁定颗粒度大所带来最大的负面影响就是出现锁定资源争用的概率也会最高，致使并大度大打折扣。

● 页级锁定（page-level）

页级锁定是MySQL 中比较独特的一种锁定级别，在其他数据库管理软件中也并不是太常见。页级锁定的特点是锁定颗粒度介于行级锁定与表级锁之间，所以获取锁定所需要的资源开销，以及所能提供的并发处理能力也同样是介于上面二者之间。另外，页级锁定和行级锁定一样，会发生死锁。

在数据库实现资源锁定的过程中，随着锁定资源颗粒度的减小，锁定相同数据量的数据所需要消耗的内存数量是越来越多的，实现算法也会越来越复杂。不过，随着锁定资源颗粒度的减小，应用程序的访问请求遇到锁等待的可能性也会随之降低，系统整体并发度也随之提升。

在MySQL 数据库中，使用表级锁定的主要是MyISAM，Memory，CSV 等一些非事务性存储引擎，而使用行级锁定的主要是Innodb 存储引擎和NDB Cluster 存储引擎，页级锁定主要是BerkeleyDB 存储引擎的锁定方式。

二、Mysql中表锁及行锁争用情况查询

1、Mysql实现的表级锁定的争用状态变量：

使用查询语句：show status like ‘table%’,查询结果如下所示：

说明：

●Table_locks_immediate:表示产生表级锁定的次数

●Table_locks_waited:表示出现表级锁定争用而发生等待的次数。

两个状态值都是从系统启动开始记录，每出现一次对应的事件则数量加1。如果Table_locks_waited值比较高，则说明系统中表级锁定争用现象比较严重，需要进一步分析为什么有那么多的锁定资源争用。

 

2、对于innodb使用的行级锁定，使用如下语句进行查询：

查询语句：show status like 'innodb_row_lock%';

查询结果：

【说明】：

● 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（等待总时长）这三项。尤其是当等待次数很高，而且每次等待时长也不小的时候，我们就需要分析系统中为什么会有如此多的等待，然后根据分析结果着手指定优化计划。

此外，Innodb 出了提供这五个系统状态变量之外，还提供的其他更为丰富的即时状态信息供我们分析使用。可以通过如下方法查看：

1. 通过创建Innodb Monitor 表来打开Innodb 的monitor 功能：

mysql> create table innodb_monitor(a int) engine=innodb;

Query OK, 0 rows affected (0.07 sec)

2. 然后通过使用“SHOW INNODB STATUS”查看细节信息（由于输出内容太多就不在此记录了）；

可能会有读者朋友问为什么要先创建一个叫innodb_monitor 的表呢？因为创建该表实际上就是告诉Innodb 我们开始要监控他的细节状态了，然后Innodb 就会将比较详细的事务以及锁定信息记录进入MySQL 的error log 中，以便我们后面做进一步分析使用。

三、MySql中表锁及行锁优化建议

●MyISAM 表锁优化建议

对于MyISAM 存储引擎，虽然使用表级锁定在锁定实现的过程中比实现行级锁定或者页级锁所带来的附加成本都要小，锁定本身所消耗的资源也是最少。但是由于锁定的颗粒度比较到，所以造成锁定资源的争用情况也会比其他的锁定级别都要多，从而在较大程度上会降低并发处理能力。

所以，在优化MyISAM 存储引擎锁定问题的时候，最关键的就是如何让其提高并发度。由于锁定级别是不可能改变的了，所以我们首先需要尽可能让锁定的时间变短，然后就是让可能并发进行的操作尽可能的并发。

1、缩短锁定时间

缩短锁定时间，短短几个字，说起来确实听容易的，但实际做起来恐怕就并不那么简单了。如何让锁定时间尽可能的短呢？唯一的办法就是让我们的Query 执行时间尽可能的短。

a) 尽两减少大的复杂Query，将复杂Query 分拆成几个小的Query 分布进行；

b) 尽可能的建立足够高效的索引，让数据检索更迅速；

c) 尽量让MyISAM 存储引擎的表只存放必要的信息，控制字段类型；

d) 利用合适的机会优化MyISAM表数据文件；

2、分离能并行的操作

说到MyISAM 的表锁，而且是读写互相阻塞的表锁，可能有些人会认为在MyISAM 存储引擎的表上就只能是完全的串行化，没办法再并行了。大家不要忘记了，MyISAM 的存储引擎还有一个非常有用的特性，那就是Concurrent Insert（并发插入）的特性。

MyISAM 存储引擎有一个控制是否打开Concurrent Insert 功能的参数选项：concurrent_insert，可以设置为0，1 或者2。三个值的具体说明如下：

a) concurrent_insert=2，无论MyISAM 存储引擎的表数据文件的中间部分是否存在因为删除数据而留下的空闲空间，都允许在数据文件尾部进行Concurrent Insert;

b) concurrent_insert=1，当MyISAM 存储引擎表数据文件中间不存在空闲空间的时候，可以从文件尾部进行Concurrent Insert;

c) concurrent_insert=0，无论MyISAM 存储引擎的表数据文件的中间部分是否存在因为删除数据而留下的空闲空间，都不允许Concurrent Insert。

3、合理利用读写优先级

在本章各种锁定分析一节中我们了解到了MySQL 的表级锁定对于读和写是有不同优先级设定的，默认情况下是写优先级要大于读优先级。所以，如果我们可以根据各自系统环境的差异决定读与写的优先级。如果我们的系统是一个以读为主，而且要优先保证查询性能的话，我们可以通过设置系统参数选项

low_priority_updates=1，将写的优先级设置为比读的优先级低，即可让告诉MySQL 尽量先处理读请求。当然，如果我们的系统需要有限保证数据写入的性能的话，则可以不用设置low_priority_updates参数了。

这里我们完全可以利用这个特性，将concurrent_insert 参数设置为1，甚至如果数据被删除的可能性很小的时候，如果对暂时性的浪费少量空间并不是特别的在乎的话，将concurrent_insert 参数设置为2 都可以尝试。当然，数据文件中间留有空域空间，在浪费空间的时候，还会造成在查询的时候需要读取更多的数据，所以如果删除量不是很小的话，还是建议将concurrent_insert 设置为1 更为合适。

● Innodb 行锁优化建议

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

要想合理利用Innodb 的行级锁定，做到扬长避短，我们必须做好以下工作：

a) 尽可能让所有的数据检索都通过索引来完成，从而避免Innodb 因为无法通过索引键加锁而升级为表级锁定；

b) 合理设计索引，让Innodb 在索引键上面加锁的时候尽可能准确，尽可能的缩小锁定范围，避免造成不必要的锁定而影响其他Query 的执行；

c) 尽可能减少基于范围的数据检索过滤条件，避免因为间隙锁带来的负面影响而锁定了不该锁定的记录；

d) 尽量控制事务的大小，减少锁定的资源量和锁定时间长度；

e) 在业务环境允许的情况下，尽量使用较低级别的事务隔离，以减少MySQL 因为实现事务隔离级别所带来的附加成本；

由于Innodb 的行级锁定和事务性，所以肯定会产生死锁，下面是一些比较常用的减少死锁产生概率的小建议，读者朋友可以根据各自的业务特点针对性的尝试：

a) 类似业务模块中，尽可能按照相同的访问顺序来访问，防止产生死锁；

b) 在同一个事务中，尽可能做到一次锁定所需要的所有资源，减少死锁产生概率；

c) 对于非常容易产生死锁的业务部分，可以尝试使用升级锁定颗粒度，通过表级锁定来减少死锁产生的概率；