Mysql 锁机制

根据上面一篇文章，我们可以知道：当发生了读-写和写-读 问题的时候，innodb 是通过 MVCC 和 undo log 实现了在不加锁的情况下的事务隔离，保证了数据安全的同时也提高了并发性能。

那么这里我们提到的锁机制就是来解决 写-写 问题。

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

一、全局锁

1. 加锁

顾名思义，全局锁就是对整个数据库实例加锁。

MySQL 提供了一个加全局读锁的方法，命令是

1	Flush tables with read lock (FTWRL)。

当你需要让整个库处于只读状态的时候，可以使用这个命令，之后其他线程的以下语句会被阻塞：

数据更新语句（数据的增删改）
数据定义语句（包括建表、修改表结构等）
更新类事务的提交语句。

全局锁的典型使用场景是，做全库逻辑备份。也就是把整库每个表都 select 出来存成文本。

2. 逻辑备份

以前有一种做法，是通过 FTWRL 确保不会有其他线程对数据库做更新，然后对整个库做备份。

注意，在备份过程中整个库完全处于只读状态。但是让整库都只读，听上去就很危险：

如果你在主库上备份，那么在备份期间都不能执行更新，业务基本上就得停摆；
如果你在从库上备份，那么备份期间从库不能执行主库同步过来的 binlog，会导致主从延迟。

官方自带的逻辑备份工具是 mysqldump。当 mysqldump 使用参数–single-transaction 的时候，导数据之前就会启动一个事务，来确保拿到一致性视图。而由于 MVCC 的支持，这个过程中数据是可以正常更新的。

但是对于 MyISAM 这种不支持事务的引擎依然会破坏数据的一致性，所以这也是DBA要求数据库引擎迁移至 innodb 的原因

不过这里也不建议使用 set global readonly = true：

在有些系统中 readonly 的值会被用来做其他逻辑，比如用来判断一个库是主库还是备库。因此，修改 global 变量的方式影响面更大。
在异常处理机制上有差异。如果执行 FTWRL 命令之后由于客户端发生异常断开，那么 MySQL 会自动释放这个全局锁，整个库回到可以正常更新的状态。而将整个库设置为 readonly 之后，如果客户端发生异常，则数据库就会一直保持 readonly 状态，这样会导致整个库长时间处于不可写状态，风险较高。

二、表级锁

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

1. 表锁

1	lock tables … read/write。

与 FTWRL 类似，可以用 unlock tables 主动释放锁，也可以在客户端断开的时候自动释放。

需要注意，lock tables 语法除了会限制别的线程的读写外，也限定了本线程接下来的操作对象。

在还没有出现更细粒度的锁的时候，表锁是最常用的处理并发的方式。而对于 InnoDB 这种支持行锁的引擎，一般不使用 lock tables 命令来控制并发，毕竟锁住整个表的影响面还是太大。

2. 元数据锁 MDL（metadata lock)

MDL 不需要显式使用，在访问一个表的时候会被自动加上。

MDL 的作用是，保证读写的正确性。

如果一个查询正在遍历一个表中的数据，而执行期间另一个线程对这个表结构做变更，删了一列，那么查询线程拿到的结果跟表结构对不上，肯定是不行的。因此，在 MySQL 5.5 版本中引入了 MDL

当对一个表做增删改查操作的时候，加 MDL 读锁

当要对表做结构变更操作的时候，加 MDL 写锁。

读锁之间不互斥，因此你可以有多个线程同时对一张表增删改查。
读写锁之间、写锁之间是互斥的，用来保证变更表结构操作的安全性。

因此，如果有两个线程要同时给一个表加字段，其中一个要等另一个执行完才能开始执行。

虽然 MDL 锁是系统默认会加的，但却是你不能忽略的一个机制。给一个表加字段，或者修改字段，或者加索引，需要扫描全表的数据。这里又要特别小心几个场景了：

关于长事务：事务不提交，就会一直占着 MDL 锁。在 MySQL 的 information_schema 库的 innodb_trx 表中，你可以查到当前执行中的事务。如果你要做 DDL 变更的表刚好有长事务在执行，要考虑先暂停 DDL，或者 kill 掉这个长事务。
当要变更的表是一个热点表，虽然数据量不大，但是上面的请求很频繁，而又不得不加个字段：这时候 kill 可能未必管用，因为新的请求马上就来了。比较理想的机制是，在 alter table 语句里面设定等待时间，如果在这个指定的等待时间里面能够拿到 MDL 写锁最好，拿不到也不要阻塞后面的业务语句，先放弃。之后开发人员或者 DBA 再通过重试命令重复这个过程。

三、行锁

MySQL 的行锁是在引擎层由各个引擎自己实现的。但并不是所有的引擎都支持行锁，比如 MyISAM 引擎就不支持行锁。

不支持行锁意味着并发控制只能使用表锁，对于这种引擎的表，同一张表上任何时刻只能有一个更新在执行，这就会影响到业务并发度。

InnoDB 是支持行锁的，这也是 MyISAM 被 InnoDB 替代的重要原因之一。

1. 两阶段锁协议

事务A	事务B
begin;
update t set k = k + 1 where id = 1;
update t set k = k + 1 where id = 2;
	begin;
	update t set k = k + 1 where id = 1;
commit;
	commit;

在这个场景下，事务B会被阻塞一直到事务A提交

在 InnoDB 事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，而是要等到事务结束时才释放。

这个就是两阶段锁协议。

所以：如果你的事务中需要锁多个行，要把最可能造成锁冲突、最可能影响并发度的锁尽量往后放！！！！！！

2. 死锁和死锁检测

当并发系统中不同线程出现循环资源依赖，涉及的线程都在等待别的线程释放资源时，就会导致这几个线程都进入无限等待的状态，称为死锁。

事务A	事务B
begin;
update t set k = k + 1 where id = 1;	begin;
	update t set k = k + 1 where id = 2;
update t set k = k + 1 where id = 2;
	update t set k = k + 1 where id = 1;
commit;
	commit;

这个时候就形成了死锁：

事务A持有 id=1 的行锁去争取 id=2 的行锁
事务B持有 id=2 的行锁去争取 id=1 的行锁

对于死锁，这里有两种解决策略：

直接进入等待，直到超时。这个超时时间可以通过参数 innodb_lock_wait_timeout 来设置。
在 InnoDB 中，innodb_lock_wait_timeout 的默认值是 50s

但是这个时间的值也是不容易确定下来的：
1. 如果时间过长，那么在产生死锁之后就需要等待很久才会退出事务，很明显拉低了数据库的并发性能
2. 如果时间太短，可能只是简单的锁等待，就会产生很多误伤
发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务，让其他事务得以继续执行。将参数 innodb_deadlock_detect 设置为 on，表示开启这个逻辑。

每一个事务都会检测死锁，那么当并发事务增多时，大量的CPU资源被用来死锁检测。最后就是CPU利用率很高却执行不了几个事务。

四、innodb 的行锁

InnoDB存储引擎有3种行锁的算法，分别是：

Record Lock: 单个记录上的锁
Gap Lock: 间隙锁，锁定一个范围，但不包括记录本身
Next-Key Lock: Gap Lock+Record Lock，锁定一个范围，并且锁定记录本身

什么是幻读：

在可重复读的隔离界别下、实行当前读的时候：一个事务(同一个read view)在前后两次查询同一范围的时候，后一次查询看到了前一次查询没有看到的行。两点需要说明：
　1、在可重复读隔离级别下，普通查询是快照读，是不会看到别的事务插入的数据的，幻读只在当前读下才会出现。
　2、幻读专指新插入的行，读到原本存在行的更新结果不算。因为当前读的作用就是能读到所有已经提交记录的最新值。

由于普通的行锁即 Record Lock 只能锁住单独的行，并不能阻止新的数据的插入，所以任然会引起幻读。

这个时候就会引入间隙锁或者是Next-key Lock来避免幻读的产生

MyISAM引擎和InnoDB引擎简单对比：

	MyISAM引擎	InnoDB引擎
主外键	不支持	支持
事务	不支持	支持
行表锁	表所.不适合高并发	行锁.适合高并发
缓存	只缓存索引	缓存索引和真实数据
表空间	小	大
关注点	性能.偏读	事务
默认安装	是	是