表锁偏读,行锁偏写
偏向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:系统启动到现在总共等待的次数
尤其是当等待次数很高,而且每次等待时长也不小的时候,我们需要分析系统中为什么会有如此多的等待,然后根据分析结果着手指定优化计划。