我一直记手写笔记，一个是手写笔记更灵活好操作，另一个就是比较方便
但我想，如果我写电子笔记，那么面试的时候我就可以写在简历上，以后就是我的亮点
一、行锁种类
1、Record Lock 2
2、Gap Lock (2,3)
3、Next-Key Lock (2,3]
（这些都在我的手写笔记里，今天着急学新知识，就不扩展了）
二、
InnoDB是支持行锁的，行锁是在索引上面加锁的，加锁的基本单位是Next-Key Lock，但是也会存在锁降级的情况，Next-Key Lock降级为Record或者Gap。
下面分为四种情况分别介绍：
· 唯一索引等值查询
· 唯一索引范围查询
· 非唯一索引等值查询
· 非唯一索引范围查询
1、唯一索引等值查询
（1）这条记录存在于数据库
正常是加Next-Key Lock，但是这条命令select * from user where id = 1 for update;只查一条，而且主键索引的时候，它也存在，加Next-Key Lock，(1,1]这样就有点浪费且奇怪，可以降级为Record锁，只锁住id=1这条就可以了。
这条记录的行锁是Record锁,表锁是IX锁。那么当其它update或者delete语句操作这条id=1时，因为有锁，其余的操作就会在后面阻塞。
为什么唯一索引等值查询并且查询记录存在的场景下，该记录的索引中的 next-key lock 会退化成记录锁？
原因就是在唯一索引等值查询并且查询记录存在的场景下，仅靠记录锁也能避免幻读的问题。
幻读的定义就是，当一个事务前后两次查询的结果集，不相同时，就认为发生幻读。
所以，要避免幻读就是避免结果集某一条记录被其他事务删除，或者有其他事务插入了一条新记录，
这样前后两次查询的结果集就不会出现不相同的情况。
（2）这条记录不存在于数据库
还是上面的那个数据库表示例，主键索引1，然后就是5，发现5大于2，这个时候就会将Next-Key Lock降级为Gap Lock，锁住（1，5）
2、唯一索引范围查询
· 大于 or 大于等于
· 小于 or 小于等于
（1）大于
事务 A 加锁变化过程如下：
最开始要找的第一行是 id = 20，由于查询该记录不是一个等值查询（不是大于等于条件查询），
所以对该主键索引加的是范围为 (15, 20] 的 next-key 锁；
由于是范围查找，就会继续往后找存在的记录，虽然我们看见表中最后一条记录是 id = 20 的记录，
但是实际在 Innodb 存储引擎中，会用一个特殊的记录来标识最后一条记录，
该特殊的记录的名字叫 supremum pseudo-record ，所以扫描第二行的时候，
也就扫描到了这个特殊记录的时候，会对该主键索引加的是范围为 (20, +∞] 的 next-key 锁。
停止扫描。
(2)大于等于
（3）小于
1）查询条件值的记录「不存在」表中的情况
2）查询条件值的记录「存在」表中的情况
（4）小于等于
1）查询条件值的记录「存在」表中的情况
3、非唯一索引等值查询
说这个之前还是得再看一下建表语句
（1）针对非唯一索引等值查询时，查询的值不存在的情况。
（2）查询的值存在的情况
因为是二级索引，所以age=22如果存在，可能不是一个，所以加锁比较特殊，一个next-key,一个gap
gap锁或者是next-key，二级索引加锁的时候，假如说二级锁（age）是(21，22) or (21,22]，age=21时，id=5，那么插入21，id<5的都可以插入成功，但如果id>=5就会阻塞
同理age=22,id=10,插入age=22、id<=10就会被阻塞，id>10就会成功、、(如果只有这一个gap锁的话，如果还有相邻的gap锁还要继续去判断)
为什么这个实验案例中，需要在二级索引索引上加范围 (22, 39) 的间隙锁？
简单来说就是，如果只加(21,22]的next-key锁，只会锁住age=22对应id的左边，右边的id没有上锁，那么就会出现幻读现象
4、非唯一索引范围查询
5、没有加索引的查询
