MySQL的锁与锁机制----锁分类

根据加锁的范围，MySQL 里面的锁大致可以分成全局锁、表级锁和行锁三类。

全局锁

全局锁指的是对整个数据库实例加锁，MySQL提供了FLUSH TABLE WITH READ LOCK，用于给全整个数据库实例加读锁。这个命令执行后，整个实例就变成只读了，增删改的DML语句与建表增加索引等DDL语句都会被堵塞。可以使用UNLOCK TABLES解锁。
整个数据库实例都变成自读了，想想就多么可怕，但是在MyISAM时代，由于MyISAM不支持事务当我们需要做全库备份的时候，只能使用这个语句，使得备份期间整个库只能是只读的，从而使得备份出来的库是一致性的。
但是对于INNODB由于支持事务，在可重复读级别下，事务开始后，会创建一个一致性视图，那么备份出来的数据，就是一致的。我们可以使用mysqldump工具添加–single-transaction 的时候，导数据之前就会启动一个事务，来确保拿到一致性视图。而由于 MVCC 的支持，这个过程中数据是可以正常更新的。

表级锁

MySQL 里面表级别的锁有两种：一种是表锁，一种是元数据锁（meta data lock，MDL)。

表锁

可以通过如下的语句添加表锁：

LOCK TABLES tbl_name [[AS] alias] lock_type [, tbl_name [[AS] alias] lock_type] ... 
lock_type: { READ [LOCAL] | [LOW_PRIORITY] WRITE } 
UNLOCK TABLES

读锁与读锁直接可以并发，读锁与写锁、写锁之间只能互斥。对表加读锁后，自己也不能对其进行修改；自己和其他线程只能读取该表。 当对某个表执加上写锁后（lock table t2 write），该线程可以对这个表进行读写，其他线程对该表的读和写都受到阻塞。现今MySQL都使用了INNODB作为默认的存储引擎了，MyISAM已经很少使用了，更多细节就不在赘述。

元数据锁（meta data lock，MDL)

MDL不需要手动加锁，当访问数据库表的时候（增删改查的DML语句），会自动加上读锁；当修改数据库表的时候（DDL语句），会给数据库加上写锁。MDL锁是为了保证数据的一致性，想想如果我们在查数据库表的时候，如果通过DML语句删除了表的一列，那么数据库应该返回什么呢？与表锁类似，读锁与读锁之间可以并发，读锁与写锁、写锁之间只能互斥。但是如果在DML期间都要加写锁，那么在持有写锁期间整个库不可读写，如果DDL是一个大表，那么是多么可怕的，为此MySQL引入了在线DDL。
更多online DDL的细节参见MySQL官方文档：online-ddl-index-operations
在线DDL只能解决DDL期间堵塞增删改查的问题，但是DDL在总是需要短暂的获取MDL写锁的，那么对于热点表，在获取到写锁前，需要等待其他事务提交或者回滚。那么对于热点表，在这之后的DDL语句都会被堵塞这也是没法接受的。此时有如下选择：
1、如果热点表有明显的业务高峰期与低峰期，可以选择在低峰期执行online DDL；
2、只能使用先在备库执行DDL(需临时关闭binlog)，执行完后进行主备切换，然后在旧的主库执行DDL(同样需临时关闭binlog)；
3、InfoQ上的gh-ost或者github/gh-ost
另外需要说明的是，虽然online DDL在DDL期间可以执行DML语句，但是DDL本身是一个重IO与CPU的操作，还是要选择业务低峰期执行。

InnoDB行锁

MySQL的行锁是由存储引擎层实现的，MySQL本身并不支持。并不是所有的存储引擎都会提供行锁，MyISAM就没有提供行锁功能，对于不支持行数的存储引擎，当我们需要修改表数据的时候，只能通过添加表锁来实现，从而严重影响并发。这也是INNODB替换MyISAM的原因之一。

两阶段锁协议

两阶段锁协议是指，在事务的执行过程中，当需要给行加锁的时候，才自动加上锁，但是直到事务提交了，锁才释放。这个告诉我们，对于并发冲突越严重的语句应该越放到事务的后面来执行。同时这也是避免大事务的原因之一，大事务会导致MySQL长时间占有锁，从而影响系统的并发。

死锁与死锁检测

正如如下的语句，当我们的SQL语句存在交叉锁的时候，就会死锁。

如上的2个事务的锁在互相等待，从而发生了死锁。INNODB提供了如下的2种策略：
1、直接进入等待，直到超时。这个超时时间可以通过参数 innodb_lock_wait_timeout 来设置。
2、发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务，让其他事务得以继续执行。将参数 innodb_deadlock_detect 设置为 on，表示开启这个逻辑。

通过超时时间来设置，设置长了，如果真发生了死锁，语句等半天了才退出；设置短了，又存在误删的情况。
为此我们一般打开死锁检测。但是打开死锁检测后，在严重并发场景下又会导致CPU占用高，如果并发是1000，当发生锁资源冲突的时候，每次执行SQL语句都要扫描全部等待同一行锁的语句，1000的并发就需要扫描1000乘以1000次=100W，时间复杂度是O(n*n)。

锁冲突策略

当出现锁冲突的时候，我们可以通过如下的2种策略：
1、控制并发，我们可以使用令牌桶等限流算法（更多限流算法参加我的博客《限流–高并发系统中的流量控制》），在数据库中间件控制并发，也可以在业务层控制并发；
2、提高并发度，比如某个热点商品的库存，我们可以通过将库存拆分成多行，每次扣减库存的时候，随机选择一行就行扣减，当选取的库存不足时，可以拒绝下单或者再次重新选择或者重新分配总行数与每一行的数量等策略。

InnoDB间隙锁

考虑如下的表

CREATE TABLE t
(
`id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
`n` INT UNSIGNED NOT NULL,
`m` INT UNSIGNED NOT NULL,
PRIMARY KEY (`id`),
KEY `n` (`n`)
)ENGINE=InnoDB;
INSERT INTO t(`id`,`n`,`m`) VALUES(10,10,10),(20,20,20),(30,30,30),(40,40,40);

事务1	事务2
BEGIN	BEGIN
SQL1:select * from t where n>0 and n<=10;
	INSERT INTO t(id,n,m) VALUES(5,5,5);
	COMMIT
SQL2:select * from t where n>0 and n<=10;
COMMIT

如果SQL2读取到新插入的值(5,5,5)，那就有幻读问题。InnoDB为了再可重复读隔离级别下，解决幻读问题，引入了间隙锁，阻止再(0,10)的间隙中插入新数据。间隙锁与间隙锁之间没有并发冲突，间隙锁与行锁也没有并发冲突，但是间隙锁会堵塞住往这个间隙中插入元素。
关于幻读的危害参加我的博客《事务的ACID特性与隔离性分析》