MySQL锁的分类
锁在 MySQL 中是非常重要的一部分，锁对 MySQL 的数据访问并发有着举足轻重的影响。
一、锁的认识
锁的解释
计算机协调多个进程或线程并发访问某一资源的机制。
锁的重要性
在数据库中，除传统计算资源（CPU、RAM、I\O等）的争抢，数据也是一种供多用户共享的资源。
如何保证数据并发访问的一致性，有效性，是所有数据库必须要解决的问题。
锁冲突也是影响数据库并发访问性能的一个重要因素，因此锁对数据库尤其重要。
锁的缺点
加锁是消耗资源的，锁的各种操作，包括获得锁、检测锁是否已解除、释放锁等 ，都会增加系统的开销。
简单的示例说明
现如今网购已经特别普遍了，比如淘宝双十一活动，当天的人流量是千万及亿级别的，但商家的库存是有限的。
系统为了保证商家的商品库存不发生超卖现象，会对商品的库存进行锁控制。当有用户正在下单某款商品最后一件时，
系统会立马对该件商品进行锁定，防止其他用户也重复下单，直到支付动作完成才会释放（支付成功则立即减库存售罄，支付失败则立即释放）。
锁的分类
按数据操作的类型来分：
- 读锁（共享锁）
- 写锁（排他锁或互斥锁）
按数据操作的粒度来分：
- 表锁
- 页锁
- 行锁
二、锁类型介绍
表锁
读锁（read lock），也叫共享锁（shared lock） 。针对同一份数据，多个读操作可以同时进行而不会互相影响（select）。
写锁（write lock），也叫排他锁（exclusive lock） 。当前操作没完成之前，会阻塞其它读和写操作（update、insert、delete）。
MyISAM存储引擎的默认锁就是表锁。
特点：
- 对整张表加锁
- 开销小
- 加锁快
- 无死锁
- 锁粒度大，发生锁冲突概率大，并发性低
结论：
- 读锁会阻塞写操作，不会阻塞读操作。
- 写锁会阻塞读和写操作。
建议：
MyISAM的读写锁调度是写优先，这也是MyISAM不适合做写为主表的引擎，因为写锁以后，其它线程不能做任何操作，大量的更新使查询很难得到锁，从而造成永远阻塞。
行锁
读锁（read lock），也叫共享锁（shared lock） 。允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。
写锁（write lock），也叫排他锁（exclusive lock）。 允许获得排他锁的事务更新数据，阻止其他事务取得相同数据集的共享锁和排他锁。
意向共享锁（IS） 一个事务给一个数据行加共享锁时，必须先获得表的IS锁。
意向排它锁（IX） 一个事务给一个数据行加排他锁时，必须先获得该表的IX锁。
InnoDB存储引擎默认锁就是行锁。
特点：
- 对一行数据加锁
- 开销大
- 加锁慢
- 会出现死锁
- 锁粒度小，发生锁冲突概率最低，并发性高
事务并发带来的问题：
- 更新丢失
- 解决方案：让事务变成串行操作，而不是并发的操作，即对每个事务开始---对读取记录加排他锁。
- 脏读
- 解决方案：隔离级别为Read uncommitted。
- 不可重读
- 解决方案：使用Next-Key Lock算法来避免。
- 幻读：
- 解决方案：间隙锁（Gap Lock）
页锁
开销、加锁时间和锁粒度介于表锁和行锁之间，会出现死锁，并发处理能力一般。
三、锁的兼容性
如果是一个事务T1获得了行r的共享锁，那么另外一个事务T2可以立即获得行r的共享锁，因为读取并没有改变行r的数据，称这种情况为锁兼容Lock Compatible。但若有其他事务T3想获得行r的排他锁，则必须等待事务T1、T2释放行r的共享锁---这种情况称为锁不兼容。
表级锁的锁模式
ＭySQL的表锁有两种模式：表共享读锁（Table Read Lock）和表独占写锁（Table Write Lock）。锁模式的兼容如下表：
|
当前锁模式/是否兼容/请求锁模式 |
None |
读锁 |
写锁 |
| 读锁 | 是 | 是 | 否 |
| 写锁 | 是 | 否 | 否 |
可见，对ＭyISAM表的读操作，不会阻塞其他用户对同一表的读请求，但会阻塞对同一表的写请求；对ＭyISAM表的写操作，则会阻塞其他用户对同一表的读和写请求；ＭyISAM表的读和写操作之间，以及写和写操作之间是串行的！（当一线程获得对一个表的写锁后，只有持有锁的线程可以对表进行更新操作。其他线程的读、写操作都会等待，直到锁被释放为止。）
MyISAM在执行查询语句（SELECT）前，会自动给涉及的所有表加读锁，在执行更新操作（UPDATE、DELETE、INSERT等）前，会自动给涉及的表加写锁，这个过程并不需要用户干预，因此用户一般不需要直接用LOCK TABLE命令给MyISAM表显式加锁。
InnoDB的行锁模式
- 共享锁（s）：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。
- 排他锁（Ｘ）：允许获取排他锁的事务更新数据，阻止其他事务取得相同的数据集共享读锁和排他写锁。
- 意向共享锁（IS）：事务打算给数据行共享锁，事务在给一个数据行加共享锁前必须先取得该表的IS锁。
- 意向排他锁（IX）：事务打算给数据行加排他锁，事务在给一个数据行加排他锁前必须先取得该表的IX锁。
InnoDB行锁模式兼容性列表：
| 当前锁模式/是否兼容/请求锁模式 | X | IX | S | IS |
| X | 冲突 | 冲突 | 冲突 | 冲突 |
| IX | 冲突 | 兼容 | 冲突 | 兼容 |
| S | 冲突 | 冲突 | 兼容 | 兼容 |
| IS | 冲突 | 兼容 | 兼容 | 兼容 |
四、如何上锁
表锁
隐式上锁（默认，自动加锁自动释放）
select //上读锁
insert、update、delete //上写锁
显式上锁（手动）
lock table tableName read;//读锁 lock table tableName write;//写锁
解锁（手动）
unlock tables;//所有锁表
行锁
隐式上锁（默认，自动加锁自动释放）
select //不会上锁
insert、update、delete //上写锁
显式上锁（手动）
select * from tableName lock in share mode;//读锁 select * from tableName for update;//写锁
解锁（手动）
- 提交事务（commit）
- 回滚事务（rollback）
- kill 阻塞进程
为什么上了写锁，别的事务还可以读操作？ 因为InnoDB有MVCC机制（多版本并发控制），可以使用快照读，而不会被阻塞。
五、行锁的实现算法
Record Lock 锁
单个行记录上的锁 。
Record Lock总是会去锁住索引记录，如果InnoDB存储引擎表建立的时候没有设置任何一个索引，这时InnoDB存储引擎会使用隐式的主键来进行锁定
Gap Lock 锁
当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的索引加锁，对于键值在条件范围内但并不存在的记录。
优点：解决了事务并发的幻读问题
不足：因为query执行过程中通过范围查找的话，他会锁定争个范围内所有的索引键值，即使这个键值并不存在。
间隙锁有一个致命的弱点，就是当锁定一个范围键值之后，即使某些不存在的键值也会被无辜的锁定，而造成锁定的时候无法插入锁定键值范围内任何数据。在某些场景下这可能会对性能造成很大的危害。
Next-key Lock 锁
同时锁住数据+间隙锁 在Repeatable Read隔离级别下，Next-key Lock 算法是默认的行记录锁定算法。
行锁的注意点
- 只有通过索引条件检索数据时，InnoDB才会使用行级锁，否则会使用表级锁(索引失效，行锁变表锁)
- 即使是访问不同行的记录，如果使用的是相同的索引键，会发生锁冲突
- 如果数据表建有多个索引时，可以通过不同的索引锁定不同的行
六、如何排查锁
表锁
查看表锁情况
show open tables;
表锁分析
show status like 'table%';
- table_locks_waited：出现表级锁定争用而发生等待的次数（不能立即获取锁的次数，每等待一次值加1），此值高说明存在着较严重的表级锁争用情况
- table_locks_immediate：产生表级锁定次数，不是可以立即获取锁的查询次数，每立即获取锁加1
行锁
行锁分析
show status like 'innodb_row_lock%';
- innodb_row_lock_current_waits //当前正在等待锁定的数量
- innodb_row_lock_time //从系统启动到现在锁定总时间长度
- innodb_row_lock_time_avg //每次等待所花平均时间
- innodb_row_lock_time_max //从系统启动到现在等待最长的一次所花时间
- innodb_row_lock_waits //系统启动后到现在总共等待的次数
information_schema 库
- innodb_lock_waits表
- innodb_locks表
- innodb_trx表
优化建议
- 尽可能让所有数据检索都通过索引来完成，避免无索引行锁升级为表锁
- 合理设计索引，尽量缩小锁的范围
- 尽可能较少检索条件，避免间隙锁
- 尽量控制事务大小，减少锁定资源量和时间长度
- 尽可能低级别事务隔离
七、死锁
指两个或者多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而导致恶性循环的现象。
产生的条件
- 互斥条件：一个资源每次只能被一个进程使用
- 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放
- 不剥夺条件：进程已获得的资源，在没有使用完之前，不能强行剥夺
- 循环等待条件：多个进程之间形成的一种互相循环等待的资源的关系
解决方案
- 查看死锁：show engine innodb status \G
- 自动检测机制，超时自动回滚代价较小的事务（innodb_lock_wait_timeout 默认50s）
- 人为解决，kill阻塞进程（show processlist）
- wait for graph 等待图（主动检测）
如何避免
- 加锁顺序一致，尽可能一次性锁定所需的数据行
- 尽量基于primary（主键）或unique key更新数据
- 单次操作数据量不宜过多，涉及表尽量少
- 减少表上索引，减少锁定资源
- 尽量使用较低的隔离级别
- 尽量使用相同条件访问数据，这样可以避免间隙锁对并发的插入影响
- 精心设计索引，尽量使用索引访问数据
- 借助相关工具：pt-deadlock-logger
八、乐观锁与悲观锁
悲观锁
解释：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。
实现机制：表锁、行锁等。
实现层面：数据库本身。
使用场景：并发量大。
乐观锁
解释：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。
实现机制：提交更新时检查版本号或者时间戳是否符合。
实现层面：业务代码。
适用场景：并发量小。
