MySQL高级学习之行锁
1.概述
行锁特点 ：偏向InnoDB 存储引擎，开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。
InnoDB 与 MyISAM 的最大不同有两点：一是支持事务；二是 采用了行级锁。
2.InnoDB的行锁模式
-
共享锁（S）：又称为读锁，简称S锁，共享锁就是多个事务对于同一数据可以共享一把锁，都能访问到数据，但是只能读不能修改。
-
排他锁（X）：又称为写锁，简称X锁，排他锁就是不能与其他锁并存，如一个事务获取了一个数据行的排他锁，其他事务就不能再获
取该行的其他锁，包括共享锁和排他锁，但是获取排他锁的事务是可以对数据就行读取和修改。
对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及数据集加排他锁（X)；
对于普通SELECT语句，InnoDB不会加任何锁；
3.行锁演示
3.1建表语句
create table test_innodb_lock(
id int(11),
name varchar(16),
sex varchar(1)
)engine = innodb default charset=utf8;
insert into test_innodb_lock values(1,'100','1');
insert into test_innodb_lock values(3,'3','1');
insert into test_innodb_lock values(4,'400','0');
insert into test_innodb_lock values(5,'500','1');
insert into test_innodb_lock values(6,'600','0');
insert into test_innodb_lock values(7,'700','0');
insert into test_innodb_lock values(8,'800','1');
insert into test_innodb_lock values(9,'900','1');
insert into test_innodb_lock values(1,'200','0');
create index idx_test_innodb_lock_id on test_innodb_lock(id);
create index idx_test_innodb_lock_name on test_innodb_lock(name);
3.2 基本演示
| 会话A | 会话B | 描述 |
|---|---|---|
 |
 |
会话AB：关闭自动提交功能 |
 |
 |
会话AB：都可以正常查询数据 |
 |
 |
会话AB：都查询id为3的数据 |
 |
 |
会话A：更新id为3的数据，但是不提交 会话B：更新id为3的数据，处于等待状态 |
 |
 |
会话A：提交事务 会话B：解除阻塞状态，更新成功，但未提交 |
| 以上都是操作同一行的数据，现在来演示 | 不同行的数据。 | |
 |
 |
会话A：更新id为1的数据。正常获取到行锁，更新成功。 会话B：由于与会话A操作的不是同一行数据，获取当前行锁，更新成功 |
4.无索引或索引失效会导致行锁升级为表锁
如果不通过索引条件检索数据，或者索引失效，那么InnoDB将对表中的所有记录加锁，实际效果跟表锁一样。
会话A：
会话B：
从上图可以看出，我们操作的是两个不同行的数据，但是会话B却发生了阻塞。这是因为sex字段定义为varchar类型，而我们在会话A中传
递的是int类型，发生了自动转换导致索引失效，进而是行锁升级为表锁，所以会话B会阻塞。
5.间隙锁
间隙锁定义
当我们用范围条件，而不是使用相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据进行加锁； 对于键值在条件范围内但并不存在的记录，叫做 "间隙（GAP）" ， InnoDB也会对这个 "间隙" 加锁，这种锁机制就是所谓的 间隙锁（Next-Key锁） 。
间隙锁危害
因为在Query执行过程中通过范围查找的话，会锁定整个范围内的所有索引键值，即使这个索引不存在。间隙锁有一个比较致命的弱点，就是当锁定一个范围键值后，即使某些不存在的键值也会被无辜的锁定，而造成在锁定的时候无法插入锁定值范围内的任何数据。在某些场景下这个可能会对性能造成很大的危害。
间隙锁演示
| 会话A | 会话B | 描述 |
|---|---|---|
 |
 |
会话A：进行范围更新。会话B：发生阻塞 |
 |
 |
会话A：提交事务。会话B：更新成功 |
注意：表中没有id为2的数据
6.如何锁定某一行
利用begin，for update语句
6.1会话A对id为5这一行数据进行锁定
6.2 会话B对id为5这一行的数据进行修改
发生阻塞
6.3会话Acommit
6.4 会话B更新成功
7. InnoDB 行锁争用情况
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: 系统启动后到现在总共等待的次数
当等待的次数很高，而且每次等待的时长也不小的时候，我们就需要分析系统中为什么会有如此多的等待，然后根据分析结果着手制定优化计划。
8.总结
InnoDB存储引擎由于实现了行级锁定，虽然在锁定机制的实现方面带来了性能损耗可能比表锁会更高一些，但是在整体并发处理能力方面要远远由于MyISAM的表锁的。当系统并发量较高的时候，InnoDB的整体性能和MyISAM相比就会有比较明显的优势。
但是，InnoDB的行级锁同样也有其脆弱的一面，当我们使用不当的时候，可能会让InnoDB的整体性能表现不仅不能比MyISAM高，甚至可能会更差。
优化建议：
- 尽可能让所有数据检索都能通过索引来完成，避免无索引行锁升级为表锁。
- 合理设计索引，尽量缩小锁的范围
- 尽可能减少索引条件，及索引范围，避免间隙锁
- 尽量控制事务大小，减少锁定资源量和时间长度
- 尽可使用低级别事务隔离（但是需要业务层面满足需求）