数据库事务锁(数据库锁机制)

软件开发 34
本篇文章给大家谈谈数据库事务锁,以及数据库锁机制对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。 关于数据库事务与加锁 由于并发操作的存在,引出了隔离级。由于对资源存在竞争,引出了锁。不同的隔离级别,区别在于锁的释放时机不同。具体选择何种隔离级别,要根据实际应用的需求。一般情况下,使用系统默认的 读提交 即可满足需求。

本篇文章给大家谈谈数据库事务锁,以及数据库锁机制对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。

关于数据库事务与加锁

由于并发操作的存在,引出了隔离级。

由于对资源存在竞争,引出了锁。

不同的隔离级别,区别在于锁的释放时机不同。

具体选择何种隔离级别,要根据实际应用的需求。一般情况下,使用系统默认的 读提交 即可满足需求。

MySQL数据库表被锁、解锁,删除事务

在程序员的职业生涯中,总会遇到数据库表被锁的情况,前些天就又撞见一次。由于业务突发需求,各个部门都在批量操作、导出数据,而数据库又未做读写分离,结果就是:数据库的某张表被锁了!

用户反馈系统部分功能无法使用,紧急排查,定位是数据库表被锁,然后进行紧急处理。这篇文章给大家讲讲遇到类似紧急状况的排查及解决过程,建议点赞收藏,以备不时之需。

用户反馈某功能页面报502错误,于是第一时间看服务是否正常,数据库是否正常。在控制台看到数据库CPU飙升,堆积大量未提交事务,部分事务已经阻塞了很长时间,基本定位是数据库层出现问题了。

查看阻塞事务列表,发现其中有锁表现象,本想利用控制台直接结束掉阻塞的事务,但控制台账号权限有限,于是通过客户端登录对应账号将锁表事务kill掉,才避免了情况恶化。

下面就聊聊,如果当突然面对类似的情况,我们该如何紧急响应?

想象一个场景,当然也是软件工程师职业生涯中会遇到的一种场景:原本运行正常的程序,某一天突然数据库的表被锁了,业务无法正常运转,那么我们该如何快速定位是哪个事务锁了表,如何结束对应的事物?

首先最简单粗暴的方式就是:重启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的锁表其实还有很多其他场景,我们在实践的过程中尽量避免锁表情况的发生,当然这需要一定经验的支撑。但更重要的是,如果发现锁表我们要能够快速的响应,快速的解决问题,避免影响正常业务,避免情况进一步恶化。所以,本文中的解决思路大家一定要收藏或记忆一下,做到有备无患,避免突然状况下抓瞎。

怎么理解数据库的锁? 一般锁分别哪几种?

数据库是一个多用户使用的共享资源。当多个用户并发地存取数据时,在数据库中就会产生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能会读取和存储不正确的数据,破坏数据库的一致性。

加锁是实现数据库并发控制的一个非常重要的技术。当事务在对某个数据对象进行操作前,先向系统发出请求,对其加锁。加锁后事务就对该数据对象有了一定的控制,在该事务释放锁之前,其他的事务不能对此数据对象进行更新操作。

在数据库中有两种基本的锁类型:排它锁(Exclusive Locks,即X锁)和共享锁(Share Locks,即S锁)。当数据对象被加上排它锁时,其他的事务不能对它读取和修改。加了共享锁的数据对象可以被其他事务读取,但不能修改。数据库利用这两种基本的锁类型来对数据库的事务进行并发控制。

扩展资料:

排它锁和共享锁的不同之处:

1、共享锁(S锁):如果事务T对数据A加上共享锁后,则其他事务只能对A再加共享锁,不能加排他锁。获准共享锁的事务只能读数据,不能修改数据。

排他锁(X锁):如果事务T对数据A加上排他锁后,则其他事务不能再对A加任任何类型的封锁。获准排他锁的事务既能读数据,又能修改数据。

2、共享锁下其它用户可以并发读取,查询数据。但不能修改,增加,删除数据,资源共享。

3、共享锁又称为读锁(Share lock,简记为S锁),若事务T对数据对象A加上S锁,则其它事务只能再对A加S锁,而不能加X锁,直到T释放A上的S锁。

参考资料:百度百科-排它锁

参考资料:百度百科-共享锁

什么是事务?什么是锁?

事务与锁是不同的。事务具有ACID(原子性、一致性、隔离性和持久性),锁是用于解决隔离性的一种机制。事务的隔离级别通过锁的机制来实现。另外锁有不同的粒度,同时事务也是有不同的隔离级别的(一般有四种:读未提交Read uncommitted,

读已提交Read committed,

可重复读Repeatable read,

可串行化Serializable)。

在具体的程序设计中,开启事务其实是要数据库支持才行的,如果数据库本身不支持事务,那么仍然无法确保你在程序中使用的事务是有效的。

锁可以分为乐观锁和悲观锁:

悲观锁:认为在修改数据库数据的这段时间里存在着也想修改此数据的事务;

乐观锁:认为在短暂的时间里不会有事务来修改此数据库的数据;

我们一般意义上讲的锁其实是指悲观锁,在数据处理过程中,将数据置于锁定状态(由数据库实现)

如果开启了事务,在事务没提交之前,别人是无法修改该数据的;如果rollback,你在本次事务中的修改将撤消(不是别人修改的会没有,因为别人此时无法修改)。当然,前提是你使用的数据库支持事务。还有一个要注意的是,部分数据库支持自定义SQL锁覆盖事务隔离级别默认的锁机制,如果使用了自定义的锁,那就另当别论。

重点:一般事务使用的是悲观锁(具有排他性)

关于数据库事务锁和数据库锁机制的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。

数据库事务锁 数据库事务锁机制数据库事务锁的级别通常包括数据库事务锁表数据库事务和锁的关系数据库事务加锁数据库事务会锁表吗数据库x锁其他事务能读嘛数据库的事务是什么数据库事务回滚数据库事务的四大特性
扫码二维码