众所周知,innodb是默认行锁,当然也支持表锁.如下是对于行锁的算法进行的一些实验.
锁的算法为：我知道是行锁,但是是如何锁的,锁多少数据
Innodb锁算法规则如下：
在可重复读隔离级别下,innodb默认使用的是next-key lock算法,当查询的索引是主键或者唯一索引的情况下,才会退化为record lock,在使用next-key lock算法时,不仅仅会锁住范围,还会给范围最后的一个键值加一个gap lock.
其中lockmode中的X锁为左边会话中的锁,因为需要显式的commit之后才会释放锁,第二个S锁,为右边的共享锁,因为主键ID为1的已经被锁住了,所以处于锁等待状态,锁的类型为record lock
所以目前被锁住的记录为：
当使用范围条件进行更新时,此时肯定是需要加X锁的,我是用的也是主键,所以按照理论应该是加的record lock ,但是却加了gap lock,因为插入值为10的阻塞了,查看information 也提示X.GAP
这个有点晕为啥主键变成了next-key lock ,不应该是record lock么?
在知乎看到的一个解释：
即,在无论使用主键索引还是非主键索引的时候,请求共享锁或者排他锁,innodb会给范围内的记录加锁,而范围内的间隙也会被加锁,
假如执行如下：
那么这个时候执行
执行
幻读是同一事务下,连续执行两次同样的sql可能导致不同的结果,第二次返回的数据可能导致以前不存在的行.
同时一般会问它和脏读的区别,脏读为读取到其他事务未提交的数据,但是幻读是读取的其他事务已经提交的数据.
reference：
在程序员的职业生涯中,总会遇到数据库表被锁的情况,前些天就又撞见一次.由于业务突发需求,各个部门都在批量操作、导出数据,而数据库又未做读写分离,结果就是：数据库的某张表被锁了！
用户反馈系统部分功能无法使用,紧急排查,定位是数据库表被锁,然后进行紧急处理.这篇文章给大家讲讲遇到类似紧急状况的排查及解决过程,建议点赞收藏,以备不时之需.
下面就聊聊,如果当突然面对类似的情况,我们该如何紧急响应?
想象一个场景,当然也是软件工程师职业生涯中会遇到的一种场景：原本运行正常的程序,某一天突然数据库的表被锁了,业务无法正常运转,那么我们该如何快速定位是哪个事务锁了表,如何结束对应的事物?
首先最简单粗暴的方式就是：重启MySQL.对的,网管解决问题的神器——"重启".至于后果如何,你能不能跑了,要你自己三思而后行了！
重启是可以解决表被锁的问题的,但针对线上业务很显然不太具有可行性.
下面来看看不用跑路的解决方案：
遇到数据库阻塞问题,首先要查询一下表是否在使用.
如果查询结果为空,那么说明表没在使用,说明不是锁表的问题.
如果查询结果不为空,比如出现如下结果：
则说明表（test）正在被使用,此时需要进一步排查.
查看数据库当前的进程,看看是否有慢SQL或被阻塞的线程.
执行命令：
该命令只显示当前用户正在运行的线程,当然,如果是root用户是能看到所有的.
在上述实践中,阿里云控制台之所以能够查看到所有的线程,猜测应该使用的就是root用户,而笔者去kill的时候,无法kill掉,是因为登录的用户非root的数据库账号,无法操作另外一个用户的线程.
如果情况紧急,此步骤可以跳过,主要用来查看核对：
看事务表INNODB_TRX中是否有正在锁定的事务线程,看看ID是否在show processlist的sleep线程中.如果在,说明这个sleep的线程事务一直没有commit或者rollback,而是卡住了,需要手动kill掉.
搜索的结果中,如果在事务表发现了很多任务,最好都kill掉.
执行kill命令：
对应的线程都执行完kill命令之后,后续事务便可正常处理.
针对紧急情况,通常也会直接操作第第一段：第第二段：第六步.
这里再补充一些MySQL锁相关的知识点：数据库锁设计的初衷是处理并发问题,作为多用户共享的资源,当出现并发访问的时候,数据库需要合理地控制资源的访问规则,而锁就是用来实现这些访问规则的重要数据结构.
根据加锁的范围,MySQL里面的锁大致可以分成全局锁、表级锁和行锁三类.MySQL中表级别的锁有两种：一种是表锁,一种是元数据锁（metadata lock,MDL).
表锁是在Server层实现的,ALTER TABLE之类的语句会使用表锁,忽略存储引擎的锁机制.表锁通过lock tables... read/write来实现,而对于InnoDB来说,一般会采用行级锁.毕竟锁住整张表影响范围太大了.
另外一个表级锁是MDL（metadata lock）,用于并发情况下维护数据的一致性,保证读写的正确性,不需要显式的使用,在访问一张表时会被自动加上.
常见的一种锁表场景就是有事务操作处于：Waiting for table metadata lock状态.
MySQL在进行alter table等DDL操作时,有时会出现Waiting for table metadata lock的等待场景.
一旦alter table TableA的操作停滞在Waiting for table metadata lock状态,后续对该表的任何操作（包括读）都无法进行,因为它们也会在Opening tables的阶段进入到Waiting for table metadata lock的锁等待队列.如果核心表出现了锁等待队列,就会造成灾难性的后果.
通过show processlist可以看到表上有正在进行的操作（包括读）,此时alter table语句无法获取到metadata 独占锁,会进行等待.
通过show processlist看不到表上有任何操作,但实际上存在有未提交的事务,可以在information_schema.innodb_trx中查看到.在事务没有完成之前,表上的锁不会释放,alter table同样获取不到metadata的独占锁.
处理方法：通过 select * from information_schema.innodb_trxG, 找到未提交事物的sid,然后kill掉,让其回滚.
通过show processlist看不到表上有任何操作,在information_schema.innodb_trx中也没有任何进行中的事务.很可能是因为在一个显式的事务中,对表进行了一个失败的操作（比如查询了一个不存在的字段）,这时事务没有开始,但是失败语句获取到的锁依然有效,没有释放.从performance_schema.events_statements_current表中可以查到失败的语句.
处理方法：通过performance_schema.events_statements_current找到其sid,kill 掉该session,也可以kill掉DDL所在的session.
都说到这里了大家应该明白,alter table的语句是很危险的（核心是未提交事务或者长事务导致的）,在操作之前要确认对要操作的表没有任何进行中的操作、没有未提交事务、也没有显式事务中的报错语句.
如果有alter table的维护任务,在无人监管的时候运行,最好通过lock_wait_timeout设置好超时时间,避免长时间的metedata锁等待.
关于MySQL的锁表其实还有很多其他场景,我们在实践的过程中尽量避免锁表情况的发生,当然这需要一定经验的支撑.但更重要的是,如果发现锁表我们要能够快速的响应,快速的解决问题,避免影响正常业务,避免情况进一步恶化.所以,本文中的解决思路大家一定要收藏或记忆一下,做到有备无患,避免突然状况下抓瞎.
重启mysql服务
行锁的等待
如上图所示,事务 A 与事务 B 同时会去 Insert 一条主键值为 1 的数据,由于事务 A 首先获取了主键值为 1 的行锁,导致事务 B 因无法获取行锁而产生等待,等到事务 A 提交后,事务 B 才获取该行锁,完成提交.这里强调的是行锁的概念,虽然事务 B 重复插入了主键,但是在获取行锁之前,事务一直是处于行锁等待的状态,只有获取行锁后,才会报主键冲突的错误.当然这种 Insert 行锁冲突的问题比较少见,只有在大量并发插入场景下才会出现,项目上真正常见的是 updatedelete 之间行锁等待,这里只是用于示例,原理都是相同的.
第三段：产生的原因根据我之前接触到的此类问题,大致可以分为以下几种原因
全局锁就是对整个数据库实例加锁,加锁后整个实例就处于只读状态,后续的DML的写语句,DDL语句,已经更新操作的事务提交语句都将阻塞.其典型的使用场景就是做全库的逻辑备份,对所有的表进行锁定,从而获取一致性视图,保证数据的完整性.但是对数据库加全局锁是有弊端的,如在主库上备份,那么在备份期间都不能执行更新,业务会受影响,第二如果是在从库上备份,那么在备份期间从库不能执行主库同步过来的二进制日志,会导致主从延迟.
解决办法是在innodb引擎中,备份时加上--single-transaction参数来完成不加锁的一致性数据备份.
添加全局锁: flush tables with read lock; 解锁 unlock tables.
表级锁,每次操作会锁住整张表.锁定粒度大,发送锁冲突的概率最高,并发读最低,应用在myisam、innodb、BOB等存储引擎中.表级锁分为: 表锁、元数据锁(meta data lock, MDL)和意向锁.
表锁又分为: 表共享读锁 read lock、表独占写锁write lock
语法: 1、加锁 lock tables 表名 ... read/write
元数据锁,在加锁过程中是系统自动控制的,无需显示使用,在访问一张表的时候会自动加上,MDL锁主要作用是维护表元数据的数据一致性,在表上有活动事务的时候,不可以对元数据进行写入操作.为了避免DML和DDL冲突,保证读写的正确性.
查看元数据锁:
select object_type,object_schema,object_name,lock_type,lock_duration from performance_schema_metadata_locks;
意向锁,为了避免DML在执行时,加的行锁与表锁的冲突,在innodb中引入了意向锁,使得表锁不用检查每行数据是否加锁,使用意向锁来减少表锁的检查.意向锁分为,意向共享锁is由语句select ... lock in share mode添加.意向排他锁ix,由insert,update,delete,select...for update 添加.
select object_schema,object_name,index_name,lock_type,lock_mode,lock_data from performance_schema.data_lock;
行级锁,每次操作锁住对应的行数据,锁定粒度最小,发生锁冲突的概率最高,并发读最高,应用在innodb存储引擎中.
innodb的数据是基于索引组织的,行锁是通过对索引上的索引项加锁来实现的,而不是对记录加的锁,对于行级锁,主要分为以下三类:
①.、行锁或者叫record lock记录锁,锁定单个行记录的锁,防止其他事物对次行进行update和delete操作,在RC,RR隔离级别下都支持.
innodb实现了以下两种类型的行锁
①.、共享锁 S: 允许一个事务去读一行,阻止其他事务获得相同数据集的排他锁.
insert 语句 排他锁 自动添加的
update语句 排他锁 自动添加
delete 语句 排他锁 自动添加
select 正常查询语句 不加锁 ...
select ...lock in share mode 共享锁 需要手动在select 之后加lock in share mode
select ...for update 排他锁 需要手动在select之后添加for update
默认情况下,innodb在repeatable read事务隔离级别运行,innodb使用next-key锁进行搜索和索引扫描,以防止幻读.
间隙锁唯一目的是防止其它事务插入间隙,间隙锁可以共存,一个事务采用的间隙锁不会阻止另一个事务在同一间隙上采用的间隙锁.
以上就是土嘎嘎小编为大家整理的mysql行锁怎么释放相关主题介绍,如果您觉得小编更新的文章只要能对粉丝们有用,就是我们最大的鼓励和动力,不要忘记讲本站分享给您身边的朋友哦！！