MySQL锁机制

一、简介

1、概述

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

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

2、锁的分类

1、从对数据操作的类型（读/写）分

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

2、从对数据操作的粒度分

• 表锁
• 行锁

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

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

二、表锁

1、概述

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

2、案例准备

1、建表sql

create table mylock(
	id int not null primary key auto_increment,
	name varchar(20)
)engine myisam;

insert into mylock(name) values('a');
insert into mylock(name) values('b');
insert into mylock(name) values('c');
insert into mylock(name) values('d');
insert into mylock(name) values('e');

2、查看所有表上添加的锁信息show open tables;

3、手动增加表锁lock table 表名 read|write;

4、释放锁unlock tables;

3、读锁案例分析

1、开两个终端，在一个终端上执行 lock table mylock read; 命令

终端一：

终端二：

分析：从上面两张图中可以看出，终端一只能读取锁定的表无法读取其他没有被锁定的表，终端二既能读取锁定的表也能读取未锁定的表。

终端一：

终端二：

分析：从上面两张图中可以看出，终端一中既不能往被锁定的表中加数据也不能往没有被锁定的表中加数据，终端二中只能往没有被锁定的表中加数据，被锁定的表加数据会一直等待（进入阻塞状态），直到终端一中释放了锁，终端二中才会添加成功。

4、写锁案例分析

1.打开两个终端，在一个终端上执行lock table mylock write;

终端一：

终端二：

分析：从上面两张图可以看出，终端一能对加锁的表进行增删改查操作，但是无法对未锁定的表进行增删改查，终端二中对加锁的表无法操作会进入（阻塞状态），直到终端一解锁，终端二上的命令才能执行，终端二，未锁定的表可以进行增删改查操作。

5、总结

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

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

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

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

三、行锁

1、概述

行锁偏向InnoDB存储引擎，开销大，加锁慢，会出现死锁，锁定粒度最小，发生锁冲突的概率最低，并发度也最高。InnoDB与MyISAM的最大不同有两点：一是支持事务（TRANSACTION）；二是采用了行级锁。

2、关于事务

事务是由一组SQL语句组成的逻辑处理单元，事务具有以下4个属性，通常简称为事务的ACID属性。

• 原子性（Atomicity）：事务是一个原子操作单元，其对数据的修改，要么全都执行，要么全都不执行。

• 一致性（Consistent）：在事务开始和完成时，数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改，以保持数据的完整性；事务结束时，所有的内部数据结构（如B树索引或双向链表）也都必须是正确的。

• 隔离性（Isolation）：数据库系统提供一定的隔离机制，保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的，反之亦然。

• 持久性（Durable）：事务完成之后，它对于数据的修改是永久性的，即使出现系统故障也能够保持。

并发事务处理带来的问题

• 更新丢失（Lost Update）：当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，由于每个事务都不知道其他事务的存在，就会发生丢失更新问题，最后的更新覆盖了由其他事务所做的更新。

• 脏读（Dirty Reads）：事务A读取到了事务B 已修改但尚未提交的的数据 ，还在这个数据基础上做了操作。此时，如果B事务回滚，A读取的数据无效，不符合一致性要求。

• 不可重复读（Non-Repeatable Reads）：事务A中多次读取数据，这时事务B对数据进行了修改，这时事务A多次读取的数据前后不一致。

• 幻读（Phantom Reads）：事务A按相同的查询条件重新读取以前检索过的数据，读取到事务B提交的新增数据，不符合隔离性。

事务隔离级别

“脏读”、“不可重复读”、“幻读”，其实都是数据库读一致性问题，必须由数据库提供一定的事务隔离机制来解决。

隔离级别	读数据一致性	脏读	不可重复度	幻读
读未提交（Read Uncommitted）	最低级别，只能保证不读取物理上损坏的数据	是	是	是
读已提交（Read Committed）	语句级	否	是	是
可重读（Repeatable Read）	事务级	否	否	是
可串行化（Serializable）	最高级别，事务级	否	否	否

数据库的事务隔离越严格，并发副作用越小，但付出的代价也就越大，因为事务隔离实质上就是使事务在一定程度上 “串行化”进行，这显然与“并发”是矛盾的。同时，不同的应用对读一致性和事务隔离程度的要求也是不同的，比如许多应用对“不可重复读”和“幻读”并不敏感，可能更关心数据并发访问的能力。

查看当前数据库的事务隔离级别：show variables like 'tx_isolation';

3、案例分析

1、建表sql

-- 建表
create table test_innodb_lock(
a int(11),
b varchar(16)
)engine=innodb;
-- 数据
insert into test_innodb_lock values(1,'b2');
insert into test_innodb_lock values(3,'3');
insert into test_innodb_lock values(4,'4000');
insert into test_innodb_lock values(5,'5000');
insert into test_innodb_lock values(6,'6000');
insert into test_innodb_lock values(7,'7000');
insert into test_innodb_lock values(8,'8000');
insert into test_innodb_lock values(9,'9000');
insert into test_innodb_lock values(1,'b1');
-- 给字段a、b分别加索引
create index test_innodb_a_ind on test_innodb_lock(a);
create index test_innodb_lock_b_ind on test_innodb_lock(b);

2、首先要关闭InnoDB的事务自动提交：set autocommit = 0，需要手动提交sql输入：commit

终端一：

终端二：

分析：从上面两张图中可以看出，终端一中关闭了自动提交，查询a=3的数据为“哈哈哈”，在终端二中查询a=3的数据发现与终端一中的数据一致，当在终端一中执行update语句后，终端一上的数据就会发生改变，终端二中的数据还是原来的数据，当终端一中执行commit后，终端二中的数据才会更新与终端一上的数据一致。

3、在终端一上执行更新并且不提交，再在终端二上执行更新就会一直等待

终端一：

终端二：

分析：终端一上更新数据没有commit，终端二执行更新就会一直阻塞，当终端一进行commit后，终端二才会执行成功，可以看到执行时间为14.52s，说明一直在等待终端一提交。如果长时间阻塞，就会报错，提示等待超时：1205 - Lock wait timeout exceeded; try restarting transaction。

4、在终端一上执行更新并且不提交，再在终端二上执行更新不同的行

终端一：

终端二：

分析：在终端一上执行更新a=3的数据，没有commit，在终端二上更新a=4的数据，发现更新成功，并没有发生阻塞情况，这也正说明InnoDB是行锁。

4、索引失效行锁变为表锁

终端一：

终端二：

分析：删除了字段b的索引，在终端一上对b=1的行进行修改操作，未提交时，再在终端二上对b=9000的行进行修改操作，发现进入了阻塞状态，从终端一commit后，终端二上的执行时间可以看出阻塞状态，这与表锁的特征相同，由此可见，索引失效行锁会变成表锁。

5、select也能加锁

1、读锁

读锁也称共享锁（Share Lock），是读取操作创建的锁，其他用户只能并发读取数据，但是不能对数据进行增删改（获取数据上的排它锁），直到释放共享锁。如果事务T对数据A加上共享锁后，则其他事务只能对A再加共享锁，不能加排他锁。

用法：select * from 表名 lock in share mode;

在查询语句后面增加 lock in share mode，Mysql会对查询结果中的每行都加共享锁，当没有其他线程对查询结果集中的任何一行使用排他锁时，可以成功申请共享锁，否则会被阻塞。

2、写锁

写锁也称排他锁（exclusive lock），如果事务T对数据A加上排他锁后，则其他事务不能再对A加任任何类型的封锁。获准排他锁的事务能对数据进行增删改查操作。

用法：select * from 表名 for update;

在查询语句后面增加for update，Mysql会对查询结果中的每行都加排他锁，当没有其他线程对查询结果集中的任何一行使用排他锁时，可以成功申请排他锁，否则会被阻塞。

6、间隙锁

1、间隙锁是什么？

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

终端一：

终端二：

分析：在终端一中执行update语句（带有范围条件的，而不是等于的），在表中不存在a=2的数据行，在终端二中新增一条a=2的数据，发现一直处于阻塞状态，这是因为条件范围内但不存在的记录也会被锁定即（间隙锁），当终端一中commit后，终端二中的sql执行成功。执行时间49.95s。

2、间隙锁危害

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

7、行锁分析

1、通过检查InnoDB_row_lock状态变量来分析系统上的行锁的争夺情况

2、参数说明

• Innodb_row_lock_current_waits：当前正在等待锁定的数量。

• Innodb_row_lock_time：从系统启动到现在锁定总时间长度（重要）。

• Innodb_row_lock_time_avg：每次等待所花平均时间（重要）。

• Innodb_row_lock_time_max：从系统启动到现在等待最常的一次所花的时间。

• Innodb_row_lock_waits：系统启动后到现在总共等待的次数（重要）。

3、查询被锁阻塞的sql语句

SELECT * FROM information_schema.INNODB_TRX;

8、优化建议

1、尽可能让所有数据检索都通过索引来完成，避免无索引行锁升级为表锁。

2、尽可能较少检索条件，避免间隙锁。

3、尽量控制事务大小，减少锁定资源量和时间长度。

4、锁住某行后，尽量不要去调别的行或表，赶紧处理被锁住的行然后释放掉锁。

5、涉及相同表的事务，对于调用表的顺序尽量保持一致。

6、在业务环境允许的情况下，尽可能低级别事务隔离。

9、总结

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