MySQL 锁机制
表锁
读锁
查看哪些表被加锁了
语法：show open tables
添加读锁
read 读锁关键字 | write 写锁关键字
语法：lock table 表名 read
解锁
语法：unlock table
场景一
当查询一加了读锁后，查询一无法进行查询其它表
-- 给student添加读锁 lock table student read
-- 当我们再去查询user表时,直接报错 select * from user
场景二
当我们去修改时，也会报错，因为加的是读锁
update student set StudentName = '小花3' where Id = 1
场景三
查询二（新建查询）中可以去查询其它表，但是修改当前表会进入阻塞状态（一直进行查询，指到解锁之后）
update student set StudentName = 'XXX5' where Id = 1
总结
加了表锁之后，查询1无法进行查询其它表(相当于这次借的钱没还，下次又来借钱，肯定是不借)，查询1不能修改当前已经被锁表和其它表，会导致报错，除非解锁后回复正常操作
在查询1加了表锁之后，查询2可以查询其它表，但不能修改其它表和当前已经锁的表，修改当前锁的表会导致一直阻塞，除非解锁后回复正常操作
写锁
场景一
--给student添加写锁 lock table student write;
查询一：可以查询当前student，但是不能查询其它表(user…)
场景二
查询一：可以修改当前表，不能修改其它表
update student set StudentName = 'XXX2' where Id = 1
场景三
查询二：不可以查询当前student，可以查询其它表(user…)
select * from student
总结
查询一添加写锁后，查询一：可以查询当前student，但是不能查询其它表(user…)，查询一：可以修改当前表，不能修改其它表，查询二：不可以查询当前student，可以查询其它表(user…)
行锁
场景一
查询一和查询二分别设置关闭自动提交
语法：set autocommit = 0;
设置（打开）自动提交
语法：set autocommit = 1;
当查询一修改完数据后，查询二中无法进行查看
查询二：执行完commit后
查询一：执行完commit后，再次查询既可看到更新后的数据
场景二
当查询二修改数据后，未进行commit时，查询一不能修改当前查询二修改的那台未进行commit时的数据，否则导致阻塞，只能等待
只要当查询二commit后，查询一才能看到更改后的数据
总结
当双方同时修改同一行数据时，修改完后必须要进行手动提交commit，对方才可以看到你修改的数据，否则你修改完后，别人是看不到的，别人也无法修改当前这条数据，否则就会出现阻塞
间隙锁
间隙锁
当我们用范围条件检索数据，并请求共享或排他锁时，InnODB会给符合条件的已有数据记录的索引项加锁:对于键值在条件范围内但并不存在的记录
这种锁机制就是所谓的间隙锁(Next-Key锁)
缺点
当锁定一个范用键值之后，即使某些不存在的键值也会被无辜的锁定，而造成在锁定的时候无法插入锁定键值范围内的任何数据。在某些场景下这可能会对性能造成很大的危害（造成间隙锁后，锁定键值范围内的数据无法插入和修改）
如何锁定一行
当前查询一窗口的某行数据被锁定时，查询二窗口无法进行修改数据，当查询一修改完提交后，查询二可以修改
语法：selectfrom test_innodb_lock where a=8 for update
只需加上 for update 关键字即可
