MySQL -- 数据库各种锁

1，数据库锁

表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。
行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。
页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般
意向锁：如果另一个任务试图在该表级别上应用共享或排它锁，则受到由第一个任务控制的表级别意向锁的阻塞。第二个任务在锁定该表前不必检查各个页或行锁，而只需检查表上的意向锁。申请行级共享锁和排他锁的时候会申请表级意向共享锁和意向排他锁
间隙锁（GAP）：间隙范围锁

1.1 全局锁

FTWRL：对整个数据库实例加锁。MySQL提供加全局读锁的方法：Flush tables with read lock(FTWRL)，可以使整个库处于只读状态。使用该命令之后，数据更新语句、数据定义语句和更新类事务的提交语句等操作都会被阻塞。
使用场景：全库逻辑备份。
风险：

1. 如果在主库备份，在备份期间不能更新，业务停摆；
2. 如果在从库备份，备份期间不能执行主库同步的binlog，导致主从延迟；
3. 官方逻辑备份工具mysqldump，当mysqldump使用参数–single-transaction的时候，会启动一个事务，确保拿到一致性视图。而由于MVCC的支持，这个过程中数据是可以正常更新的。
4. 一致性读前提是引擎要支持这个隔离级别。如果要全库只读，也建议不使用set global readonly=true的方式
5. 在有些系统中，readonly的值会被用来做其他逻辑，比如判断主备库。所以修改global变量的方式影响太大。
6. 在异常处理机制上有差异。如果执行FTWRL命令之后由于客户端发生异常断开，那么MySQL会自动释放这个全局锁，整个库回到可以正常更新的状态。而将整个库设置为readonly之后，如果客户端发生异常，则数据库就会一直保持readonly状态，这样会导致整个库长时间处于不可写状态，风险较高。

1.2 表级锁

表锁（ lock tables … read/write）

-- t_user可读可写，user只读
lock tables t_user write, user read; 
-- 释放所有表锁，或者断开连接
unlock tables ;

可以用unlock tables主动释放锁，也可以在客户端断开的时候自动释放。lock tables语法除了会限制别的线程的读写外，也限定了本线程接下来的操作对象。InnoDB支持行锁的引擎，一般不使用lock tables命令来控制并发，毕竟锁住整个表的影响太大。

元数据锁（meta data lock，MDL)
访问表的时候自动加上，保证读写的正确性。表做增删改查操作的时候，加MDL读锁；结构变更操作的时候，加MDL写锁，MDL直到事务提交才会释放，需要注意长事务的出现。
读锁之间不互斥，可以有多个线程同时对一张表增删改查。读写锁之间、写锁之间是互斥的，用来保证变更表结构操作的安全性。有两个线程要同时给一个表加字段，其中一个要等另一个执行完才能开始执行。

1.3 行锁

两阶段锁
在 InnoDB 事务中，行锁是在需要的时候才加上的，但不是不需要了就释放， 而是事务结束时才释放。如果事务中需要锁多个行，要把最可能造成锁冲突、最可能影响并发度的锁尽量往后放。
死锁
并发系统中不同线程出现循环资源依赖，涉及的线程都在等待别的线程释放资源时，就会导致这几个线程都进入无限等待的状态。（如下表格出现死锁）
解决方案：

1. 通过参数 innodb_lock_wait_timeout 根据实际业务场景来设置超时时间，InnoDB引擎默认值是50s；
2. 发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务，让其他事务得以继续执行。将参数innodb_deadlock_detect设置为on，表示开启这个逻辑；

事务一	事务二
begin ；
update table_user set name=‘张三’ where id=1；	begin；
	update table_user set name=‘张三疯’ where id=2；
update table_user set name=‘张三’ where id=2；
	update table_user set name=‘张三疯’ where id=1；

性能问题

1. 能确保这个业务一定不会出现死锁，可以临时把死锁检测关闭掉。一般不建议采用；
2. 控制并发度，对应相同行的更新，在进入引擎之前排队。这样在InnoDB内部就不会有大量的死锁检测工作了；
3. 将热更新的行数据拆分成逻辑上的多行来减少锁冲突，但是业务复杂度可能会大大提高；

1.4 间隙锁（GAP）

两原则、两优化、一问题 , 解决RR可重复读下的幻读问题

原则1：加锁的基本单位是 next-key lock，前开后闭区间。next-key lock 是间隙锁和行锁加起来的结果
原则2：查找过程中访问到的对象才会加锁。
优化1：索引上的等值查询，给唯一索引加锁的时候，next-key lock 退化为行锁。
优化2：索引上的等值查询，向右遍历时且最后一个值不满足等值条件的时候，next-key lock 退化为间隙锁。
问题：唯一索引上的范围查询会访问到不满足条件的第一个值为止。

CREATE