mysql高级之锁（2）

表锁:

可以看我上篇博客：https://blog.csdn.net/tuesdayma/article/details/81901679

行锁

概述： 行锁主要正针对于innodb（mysql5.5之后默认存储引擎）的存储引擎而言的，每次对数据库操作都会进行行锁。

特点：

1、开销大，加锁慢，会出现死锁；发生锁冲突的概率低，并发度很高。

2、会产生间隙锁，从而导致程序无法插入问题。

3、无索引或者索引失效的记录会变成表锁。

4、个人觉得，行锁没有读写锁之分，至少测出来没有。

优化建议：

1、尽可能所有的查询条件都使用索引，避免从行锁变成了表锁。

2、尽量缩小更新范围，避免出现间隙锁。

3、合理设计索引，避免出现表锁。

演示

结论1：其他session没法读取其他session中未提交的事务（mysql默认事务级别是可重复读，不会出现脏读）

结论2：当前session更新之后不提交的话（即行锁不释放的话），其他session是无法进行更新操作的。

补充1： 上图也可以看到，其实第二个session执行update操作已经超时了，那么当前session提交事务之后能不能执行第二个session的update操作呢，显然是不行了。。。

补充2： 如果当前session提交的延迟较小，其他session的update操作还是能进行的。这里有个Lock wait timeout的概念。

结论3：索引失效或者无索引的话，行锁将变成表锁。（我们增加一个deptno这个varchar类型的字段，然后减伤索引）

alter table test03 add deptno varchar (3)  default '111';
create index index_deptno on test03(deptno);

间隙锁： 当我们where条件是一个范围，而这个范围中并不存在的记录，innodb也会对其进行加锁，这就是间隙锁（Next-Key锁），这些不存在的记录成为间隙（GAP）。

分析：当session1执行所有deptno修改的时候，age=2的那条记录虽然不在，但是也上了锁，这就是间隙锁，这时候如果其他session对间隙锁中的记录进行编辑的话，是会进入阻塞状态的，直到session1提交事务或者超时。如果未超时还是能正常执行的，但是结果中的deptno是不会变了的，新增是能成功的！

危害：当锁定一个范围之后，即使不存在的记录也不会被锁定，从而导致其他session无法进行插入范围之内不存在的记录。

如何手动锁定一行：

释放行锁： 在没有超时的前提下，其他session的update操作执行了。

结论4： 行锁是针对编辑操作的，对查询操作是不起作用的。

分析行锁：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：系统启动到现在总共等待的次数

结论5： update的时候，事务不提交的前提下，如果where条件走索引，则是行锁，那么，其他session中就能update其他行的数据；如果where条件没有走索引，那么mysql会将整个表锁住，这个时候其他session是不允许update任何数据的

结论6： update的时候，在事务不提交的前提下，另启一个session操作insert的时候：

• update的where条件走索引：允许insert；
• update的where条件不走索引：不允许insert；

结论7： update的时候，在事务不提交的前提下，另启一个session操作delete的时候：

• update的where条件和delete的where条件都走索引：允许delete；
• update的where条件不走索引，delete的where条件走索引：允许delete；
• update的where条件走索引，delete的where条件不走索引：不允许delete；
• update的where条件和delete的where条件都不走索引：不允许delete；