什么是锁
在对共享资源并发访问时，锁用来保障数据的准确。通俗点理解，锁就类似于排队，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中的意向锁都是表锁。
下面来看看共享锁、排他锁、意向共享锁、意向排他锁的兼容性
加锁以及查看
加锁
针对某条记录的修改和删除会隐式的加一把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锁
这两种形式的查询语句要放在事务当中，一旦事务提交了，锁也就释放了。
