深圳网站建设代理商,wordpress回帖可见,福田蒙派克10座车图片,小公司做网站赚钱吗锁
mysql锁的分类
从性能上分为#xff1a;乐观锁、悲观锁从锁的粒度上分#xff1a;行锁、间隙锁、页锁、悲观锁从对数据库的操作分类#xff1a;读锁、写锁
乐观锁需要我们自己通过version字段来实现#xff0c;如果更新失败则在代码中进行where重试。而我们常见的读锁…锁
mysql锁的分类
从性能上分为乐观锁、悲观锁从锁的粒度上分行锁、间隙锁、页锁、悲观锁从对数据库的操作分类读锁、写锁
乐观锁需要我们自己通过version字段来实现如果更新失败则在代码中进行where重试。而我们常见的读锁和写锁就是悲观锁。乐观锁适合于读多的场景悲观锁适合于写多的场景
读锁
共享锁
select * from tableName where id1 lock in share mode写锁
排他锁
select * from T where id1 for update行锁
InnoDB的行锁不是锁的一行记录而是针对索引加的锁。如果在更新时 where字句后面的字段没有索引或者是索引失效那么此时行锁则会升级为表锁只有可重复读隔离级别才会进行锁升级RC隔离级别不会
在InnoDB存储引擎中读未提交、读已提交、可重复读隔离界别下进行查询操作是不会加读锁的进行更新操作时会加写锁如果更新的数据存在则是加行锁如果更新的数据不存在则会变为间隙锁锁住一个区间。如果更新的字段没有索引则会从行锁/间隙锁升级为表锁(RR隔离级别下才会升级)。在串行化隔离界别下查询操作会加读锁更新操作会加写锁。
而MyISAM存储引擎进行读操作时会加读锁进行更新操作时会加写锁这里都是表锁
为什么在可重复读隔离界别下可能会出现行锁升级为表锁
这是因为它需要满足可重复读和解决幻读问题进行更新操作时会去扫描聚集索引为了避免其他事务更改已经扫描过后的数据 进而造成不可重复读和幻读问题的出现才会去进行表锁。这里也不是真正意义上的加一个表锁因为此时可能会有其他行被其他事务锁住它实际上是为每条数据和各个间隙加锁
间隙锁
锁的是一个区间(n,m)它只有在可重复读隔离界别下才有间隙锁因为它是来避免幻读问题的。
在更新时如果要更新的数据不存在此时则会创建间隙锁吗锁住当前这个区间。
Next-key 锁
是行锁间隙锁锁的区间是(n,m]
页锁
页锁只有在BDB存储引擎下才会存在了解即可
表锁
相比较于行锁而言表锁的加锁粒度更大加锁开销更小锁冲突可能性更高
意向锁
它的目的是提高加表锁的效率当我们加行锁时就会为这张表加一个意向锁其实就是在表上有一个字段标识位。
如果某条数据被某个事务加了行锁此时其他事务是不能加表锁的会有锁冲突
当如果需要加表锁时就不需要去一行一行去遍历数据行 检查此时有没有加行锁而是直接检查这个标识位就可以确定当前能不能加表锁。
意向锁也分为意向读锁、意向写锁 锁等待分析
通过检查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: 系统启动后到现在总共等待的次数
对于这5个状态变量比较重要的主要是
Innodb_row_lock_time_avg 等待平均时长Innodb_row_lock_waits 等待总次数Innodb_row_lock_time等待总时长
尤其是当等待次数很高而且每次等待时长也不小的时候我们就需要分析系统中为什么会有如此多的等待然后根据分析结果着手制定优化计划。
查看INFORMATION_SCHEMA系统库锁相关数据表
-- 查看事务
select * from INFORMATION_SCHEMA.INNODB_TRX;
-- 查看锁8.0之后需要换成这张表performance_schema.data_locks
select * from INFORMATION_SCHEMA.INNODB_LOCKS;
-- 查看锁等待8.0之后需要换成这张表performance_schema.data_lock_waits
select * from INFORMATION_SCHEMA.INNODB_LOCK_WAITS; -- 释放锁trx_mysql_thread_id可以从INNODB_TRX表里查看到
kill trx_mysql_thread_id-- 查看锁等待详细信息
show engine innodb status; 死锁问题分析
-- 先修改数据库隔离界别
set tx_isolationrepeatable-read;-- 接下来就会造成死锁当然是需要begin各自开启一个事务再开始执行下面的语句
Session_1执行select * from account where id1 for update;
Session_2执行select * from account where id2 for update;
Session_1执行select * from account where id2 for update;
Session_2执行select * from account where id1 for update;-- 查看近期死锁日志信息
show engine innodb status; 大多数情况mysql可以自动检测死锁并回滚产生死锁的那个事务但是有些情况mysql没法自动检测死锁这种情况我们可以通过日志分析找到对应事务线程id可以通过kill杀掉。 锁优化实践
让数据检索走索引避免无索引导致行锁升级为表锁的情况尽可能减少范围查询避免间隙锁尽量控制事务大小控制锁定资源量与时长涉及到事务加锁的sql操作尽量放在事务后面执行为了提高效率尽可能使用低事务隔离级别
