mysql行锁

表锁偏读，行锁偏写

偏向InnoDB存储引擎，开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。

InnoDB与MYISAM的最大不同的两点：①支持事务；②采用行级锁

---

前提知识：

并发事务处理带来的问题：

更新丢失：

脏读：

不可重复读：

幻读：

 使用事务隔离级别解决以上问题：（mysql默认的隔离级别是可重复读）

---

 行锁演示，事务默认添加行锁

！！！建索引

 

第一步操作为取消事务自动提交，方便演示（mysql5.5以后是默认自动提交事务）

 只要不是操作同一行就互不影响

---

【无索引行锁升级为表锁】

建表时 a是int类型，b是varchar类型

这个时候各自操作不同的行，互不影响

但是！！

 【为什么会阻塞？】

答：由于此时左边的update的b是int类型（原先b是varchar类型，但是mysql的底层可以自动类型转换），导致 b的索引失效！！导致行锁升级为表锁！

 总结：InnoDB的行锁是针对索引加的锁，不是针对记录加的锁。并且该索引不能失效，否则都会从行锁升级为 表锁。

【如何锁定一行？】使用for update

相关内容：

https://www.cnblogs.com/h-c-g/p/10234477.html

 

【如何分析行锁】

 通过检查InnoDB_row_lock状态变量来分析系统上的行锁的争夺情况

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

尤其是当等待次数很高，而且每次等待时长也不小的时候，我们需要分析系统中为什么会有如此多的等待，然后根据分析结果着手指定优化计划。