mysql中锁的概念_MySQL中的锁1-基本概念

什么是锁

在对共享资源并发访问时，锁用来保障数据的准确。通俗点理解，锁就类似于排队，Java中synchronized锁是在对象头上进行排队，分布式锁是在一个公用的存储服务上排队，而数据库中的锁是在所操作记录的对象上排队。

MySQL中锁的类型

各大主流数据库都会有锁的实现，而锁正是数据库区别于文件系统的特性之一。不仅不同数据库之间锁的实现不同，MySQL中不同存储引擎对于锁的实现也各不相同。

大体而言MySQL数据库中既有表锁，又有行锁。在Innodb存储引擎中会使用到下列这些锁：

Shared and Exclusive Lock

Intention Lock

Record Lock

Gap Lock

Next-Key Lock

Insert Intention Lock

AUTO-INC Locks

MyISAM中实现的锁是表锁，并发情况下的读没有问题，但是并发插入的性能很差。InnoDB实现的是行锁，锁定粒度小并发度高。MySQL默认的存储引擎是InnoDB，且官方目前打算不再继续对其他存储进行开发维护，所以这里我们讨论的锁都是基于InnoDB存储引擎。

锁都是锁在索引上的，无论是聚集索引(主键)还是二级索引

在InnoDB中行锁的模式有两种：

共享锁(S Lock)，允许事务读取一行数据。

排他锁(X Lock)，允许事务删除或者更新一行数据。

意向锁

除了行级别的锁，InnoDB中还支持表级别的锁。为了实现多粒度的锁(多粒度的锁表示在数据库中不但能实现行级别的锁，还可以实现页级别的锁，表级别的锁甚至数据库级别的锁)，InnoDB还支持另外一种锁的模式，意向锁。意向锁主要是为了在一个事务中揭示下一行将被请求的锁类型。InnoDB同样支持两种意向锁：

意向共享锁(IS Lock)，事务想要获取表中某几行的共享锁。

意向排他锁(IX Lock)，事务想要获取表中某几行的排他锁。

意向锁的工作方式

MySQL加锁的方式是从上往下一层层加的。如果事务A要在记录1上加一把X锁，则步骤如下：

在记录1所在的数据库上加一把意向锁IX;

在记录1所在的表上加一把意向锁IX；

在记录1所在的页上加一把意向锁IX；

在记录1上加一把X锁。

InnoDB没有数据库级别的锁，也没有页级别的锁，InnoDB只能在表和记录上加锁，所以InnoDB的意向锁只能加在表上，即InnoDB中的意向锁都是表锁。

下面来看看共享锁、排他锁、意向共享锁、意向排他锁的兼容性

InnoDB中锁的兼容性

加锁以及查看

加锁

针对某条记录的修改和删除会隐式的加一把X锁，如果正对查询也想要加锁就需要在SQL语句中显示的指定。

查询操作通过在SQL语句的末尾处增加for update来加X锁

select * from t1 where a=1 for update;

查询操作通过在SQL语句的末尾处增加lock in share mode来加S锁

select * from t1 where a=1 lock in share mode;

锁超时

当产生锁竞争时，如果持有锁的一方迟迟不释放锁，这时请求锁的事务(或session)会一直等待锁的释放。但是这个等待锁的过程是有等待超时的，通过innodb_lock_wait_timeout变量进行设置，默认50s。也就是说等待50秒后还没有获取到锁就放弃等待，同时抛出错误ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

锁等待超时

查看

可以通过show engine innodb status\G;指令来查看加锁的情况，该指令会显示很多和innodb存储引擎相关的运行信息，其中TRANSACTIONS表示和锁相关的信息。默认显示的情况如下：

如果想要显示更详细的信息，可以将innodb_status_output_locks参数打开，在MySQL5.7中其默认是关闭的。

打开之后我们可以看到关于锁更详细的信息

-- Record lock : 表示是锁住的记录

-- heap no 2 PHYSICAL RECORD: n_fields 5 : 表示锁住记录的heap no 为2的物理记录，由5个列组成

-- compact format : 表示这条记录存储的格式(Dynamic其实也是compact的格式)

-- info bits : 0 -- 表示这条记录没有被删除; 非0 -- 表示被修改或者被删除(32)

在MySQL5.7之后的版本中，我们可以通过sys库下的innodb_lock_waits表来查看更详细的信息，注意只有当产生了锁等待时该表中才会有记录。

select * from innodb_lock_waits\G;

*************************** 1. row ***************************

wait_started: 2018-07-15 12:06:27 -- 开始的时间

wait_age: 00:00:09 -- 等待的时间

wait_age_secs: 9 -- 等待的秒数

locked_table: `test`.`t1` -- 锁主的表(意向锁)

locked_index: GEN_CLUST_INDEX -- 锁住的是系统生成的聚集索引，锁都是在索引上的

locked_type: RECORD -- 锁的类型，记录锁

waiting_trx_id: 421992807332576 -- 等待锁的事务ID

waiting_trx_started: 2018-07-15 12:06:27

waiting_trx_age: 00:00:09

waiting_trx_rows_locked: 1

waiting_trx_rows_modified: 0

waiting_pid: 13

waiting_query: select * from t1 where a=2 lock in share mode -- 等待锁的SQL语句

waiting_lock_id: 421992807332576:25:3:2 -- 事务ID:space:page_no:heap_no

waiting_lock_mode: S -- 等待的锁的模式

blocking_trx_id: 3338

blocking_pid: 12

blocking_query: NULL

blocking_lock_id: 3338:25:3:2

blocking_lock_mode: X -- 阻塞的锁的类型

blocking_trx_started: 2018-07-15 12:04:41

blocking_trx_age: 00:01:55

blocking_trx_rows_locked: 2

blocking_trx_rows_modified: 0

sql_kill_blocking_query: KILL QUERY 12

sql_kill_blocking_connection: KILL 12 -- 给出了建议

1 row in set, 3 warnings (0.00 sec)

下面列举一下通过show engine innodb status\G指令看到的各种锁的样子。

1. 意向锁

TABLE LOCK table `test`.`t3` trx id 3962 lock mode IX

2. Record Locks

RECORD LOCKS space id 39 page no 3 n bits 72 index PRIMARY of table `test`.`t3` trx id 3962 lock_mode X locks rec but not gap

2.1 从index PRIMARY可以看出该锁加在主键上

2.2 记录锁除了lock_mode X locks rec but not gap还有lock_mode S locks rec but not gap

3. Gap Locks

RECORD LOCKS space id 39 page no 5 n bits 72 index c of table `test`.`t3` trx id 3962 lock_mode X locks gap before rec

4. Next-Key Locks

RECORD LOCKS space id 39 page no 5 n bits 72 index c of table `test`.`t3` trx id 3962 lock_mode X

5. Insert Intention Locks

RECORD LOCKS space id 279 page no 3 n bits 72 index PRIMARY of table `test`.`t3` trx id 133587907 lock_mode X insert intention waiting

6. AUTO-INC Locks

TABLE LOCK table xx trx id 7498948 lock mode AUTO-INC waiting

读与MVCC

我们知道如果某行数据加了X锁， 就没法加S锁，即没法读了，不过在实际情况中一般数据库中都允许并发读的，即使要读取的记录上存在X锁。普通的读操作(非for update和lock in share mode)不会加锁。那么在MySQL中如何保障存在DDL的并发操作中读的一致性呢？Innodb使用了MVCC技术来保证读的一致性。

MVCC (Multiversion Concurrency Control)，即多版本并发控制技术,它使得大部分支持行锁的事务引擎，不再单纯的使用行锁来进行数据库的并发控制，取而代之的是把数据库的行锁与行的多个版本结合起来，只需要很小的开销,就可以实现非锁定读，从而大大提高数据库系统的并发性能

如果要读取的行上存在X锁，这时读操作不会等行上X锁的释放，而是去读取行的一个快照版本。由于没有事务会对快照数据进行修改，所以对于快照的读取是不用上锁的。

在read committed和repeatable read的事务隔离级别中，都是使用MVCC进行读操作。不过这两种隔离级别在选择哪个快照版本进行读取问题上存在区别，区别如下：

read committed选择最新的快照版本进行读(事务A)，如果其他事务(事务B)对要读取的行进行了更新并提交。则在事务A再进行读时读取到的数据版本是事务B提交修改后形成的最新快照版本。

repeatable read读取的是事务(事务A)一开始时记录的快照版本，即使后面事务B对数据进行了修改并提交，只要事务A没有提交，那么在事务A中读取的版本依然是一开始的快照版本。

这也就能说明为啥在read committed中存在不可重复读现象，而repeatable read不存在。

MVCC实现读是不需要加锁的，MySQL当中除了MVCC的方式之外，我们还可以通过显示的加锁来保证并发过程中数据读取的一致性。可以通过下面两种方式显式的加锁：

select ... for update; 加X锁

select ... lock in share mode; 加S锁

这两种形式的查询语句要放在事务当中，一旦事务提交了，锁也就释放了。