4 InnoDB锁
InnoDB与MyISAM的最大不同有两点
- 支持事务
- 采用行锁
行级锁和表级锁本来就有许多不同之处，另外，事务的引入也带来了一些问题。
查看Innodb行锁争用情况
如果发现争用比较严重，如Innodb_row_lock_waits和Innodb_row_lock_time_avg的值比较高
查询information_schema相关表来查看锁情况
设置Innodb monitors
进一步观察发生锁冲突的表，数据行等，并分析锁争用的原因
停止监视器
默认情况每15秒会向日志中记录监控的内容;
如果长时间打开会导致.err文件变得非常巨大;
所以确认原因后,要删除监控表关闭监视器,或者通过使用–console选项来启动服务器以关闭写日志功能
4.4 InnoDB的行锁
InnoDB支持以下两种类型的行锁
- 共享锁（读锁S）
- 若事务 T 对数据对象 A 加了 S 锁;
则事务 T 可以读 A 但不能修改 A;
其它事务只能再对它加 S 锁,而不能加 X 锁,直到 T 释放 A 上的 S 锁;
这保证了,其他事务可以读 A，但在事务 T 释放 S 锁之前，不能对 A 做任何修改操作.
排他锁（写锁X）
若事务 T 对数据对象A加 X 锁;
事务 T 可以读 A 也可以修改 A;
其他事务不能对 A 加任何锁,直到 T 释放 A 上的锁;
这保证了,其他事务在 T 释放 A 上的锁之前不能再读取和修改 A .
MySQL InnoDB默认行级锁
行级锁都是基于索引的,若一条SQL语句用不到索引是不会使用行级锁的,会使用表级锁把整张表锁住
为了允许行/表锁共存，实现多粒度锁，InnoDB还有两种内部使用的：
意向锁（Intention Locks）
这两种意向锁都是表级锁：
- 意向共享锁（IS）
- 事务打算给数据行共享锁，事务在给一个数据行加共享锁前必须先取得该表的IS锁
- 意向排他锁（IX）
事务打算给数据行加排他锁，事务在给一个数据行加排他锁前必须先取得该表的IX锁
| 当前锁/是否兼容/请求锁 | X | IX | S | IS |
| X | 冲突 | 冲突 | 冲突 | 冲突 |
| IX | 冲突 | 兼容 | 冲突 | 兼容 |
| S | 冲突 | 冲突 | 兼容 | 兼容 |
| IS | 冲突 | 兼容 | 兼容 | 兼容 |
如果一个事务请求的锁模式与当前锁兼容，InnoDB就请求的锁授予该事务，反之如果两者不兼容，该事务就要等待锁释放
意向锁是InnoDB自动加的，不需用户干预.
对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及及数据集加排他锁（Ｘ）;
对于普通SELECT语句，InnoDB不会加任何锁.
对于SELECT语句,可以通过以下语句显式地给记录加读/写锁
共享锁（Ｓ）
排他锁（X）
共享锁语句主要用在需要数据依存关系时确认某行记录是否存在;
并确保没有人对这个记录UPDATE或DELETE.
但如果当前事务也需要对该记录进行更新,则很有可能造成死锁;
对于锁定行记录后需要进行更新操作的应用,应该使用排他锁语句.
此外还有自增锁（auto-in）和 lock tables/DDL等表级锁
查看锁：
SHOW ENGINE INNODB STATUS;
4.5 实例
4.5.1 Innodb共享锁
| session_1 | session_2 |
| set autocommit=0,select * from actor where id =1 | set autocommit=0,select * from actor where id =1 |
| 当前seesion对id为1的记录加入共享锁 select * from actor where id =1 lock in share mode | |
| 其他seesion仍然可以查询，并对该记录加入 select * from actor where id =1 lock in share mode | |
| 当前session对锁定的记录进行更新，等待锁 update。。。where id=1 | |
| 当前session对锁定记录进行更新，则会导致死锁退出 update。。。where id=1 | |
| 获得锁，更新成功 |
4.5.2 Innodb排他锁
| session_1 | session_2 |
| set autocommit=0,select * from actor where id =1 | set autocommit=0,select * from actor where id =1 |
| 当前seesion对id为1的记录加入for update 共享锁 select * from actor where id =1 for update | |
| 可查询该记录select *from actor where id =1,但是不能再记录共享锁，会等待获得锁select *from actor where id =1 for update | |
| 更新后释放锁 update。。。 commit | |
| 其他session，获得锁，得到其他seesion提交的记录 |
4.6 行锁的实现
行锁是通过给索引上的索引项加锁来实现。若没有索引，InnoDB将通过隐藏的聚簇索引来对记录加锁：
Record Locks
对索引项加锁
Gap lock
对索引项之的“间隙“，第一条记录前的”间隙“，或最后一条记录后的”间隙“，加锁
Next-key lock
前两种的组合，对记录及其前面的间隙加锁
行锁实现特点意味着：
若不通过索引条件检索数据，则Innodb将对表的所有记录加锁，和表锁一样。
记录锁（Record Locks）
record lock是对索引加的锁。例如，
SELECT c1 FROM t WHERE c1 = 10 FOR UPDATE;
阻止任何其他事务插入、更新或删除 t.c1=10 的行。
Record Locks总是锁定索引记录，即使表没有定义索引。对于这种情况，InnoDB 会创建一个隐藏的聚集索引并使用该索引进行记录锁定。
record lock的事务数据在 SHOW ENGINE INNODB STATUS 和 InnoDB 监视器输出中显示类似于以下内容：
RECORD LOCKS space id 58 page no 3 n bits 72 index `PRIMARY` of table `test`.`t` trx id 10078 lock_mode X locks rec but not gap Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0 0: len 4; hex 8000000a; asc ;; 1: len 6; hex 00000000274f; asc 'O;; 2: len 7; hex b60000019d0110; asc ;;
间隙锁（Next-Key锁）
当我们用范围条件而不是相等条件检索数据,并请求共享或排他锁时,InnoDB会给符合条件的已有数据的索引项加锁;
对于键值在条件范围内但并不存在的记录,叫做“间隙(GAP)”,InnoDB也会对这个“间隙”加锁,这种锁机制就是所谓的间隙锁（Next-Key锁）.
举例来说，假如emp表中只有101条记录，其empid的值分别是1,2,…,100,101，下面的SQL：
InnoDB 不仅会对符合条件的 empid 值为 101 的记录加锁;
也会对 empid大于101（这些记录并不存在）的“间隙”加锁
作用
- 防止幻读,以满足相关隔离级别的要求
对于上例,若不使用间隙锁,如果其他事务插入 empid 大于 100 的任何记录,;
那么本事务如果再次执行上述语句,就会发生幻读 - 满足其恢复和复制的需要
在使用范围条件检索并锁定记录时;
InnoDB 这种加锁机制会阻塞符合条件范围内键值的并发插入,这往往会造成严重的锁等待;
因此,在实际开发中,尤其是并发插入较多的应用;
我们要尽量优化业务逻辑,尽量使用相等条件来访问更新数据,避免使用范围条件.
