2020-07-08:mysql只有一个表a,什么情况下会造成死锁,解决办法是什么?

2020-07-08:mysql只有一个表a,什么情况下会造成死锁,解决办法是什么?,第1张

你好,很高兴回答你的问题。

两个事务t1和t2,假如t1先对表a的记录a1加了锁,而t2对表a的记录a2加了锁。

然后t1又需要对a2加锁,t2又需要对a1加锁。

这时候就会因为持有对方需要的锁,而又等待对方释放自己需要的锁,导致死锁

比如两个账户记录转账,两个事务,一个事务是从a转账给b,一个事务是从b转账给a。如果如果都是先给转出账户(或转入账户)加锁,然后给转入账户(或转出账户)加锁。就可能出现死锁。

这个可以通过加锁时都是先给主键值小的记录加锁,然后给主键值大的记录加锁,就会避免出现死锁了。

如果有帮助到你,请点击采纳。

我解答的大部分是软件开发新人遇到的问题,如果有兴趣可以关注我。

这是我见的一个文档,虽然我看不懂,你看看有没有帮助

MySQL死锁问题的相关知识是本文我们主要要介绍的内容,接下来我们就来一一介绍这部分内容,希望能够对您有所帮助。

1、MySQL常用存储引擎的锁机制

MyISAM和MEMORY采用表级锁(table-level locking)

BDB采用页面锁(page-level locking)或表级锁,默认为页面锁

InnoDB支持行级锁(row-level locking)和表级锁,默认为行级锁

2、各种锁特点

表级锁:开销小,加锁快不会出现死锁锁定粒度大,发生锁冲突的概率最高,并发度最低

行级锁:开销大,加锁慢会出现死锁锁定粒度最小,发生锁冲突的概率最低,并发度也最高

页面锁:开销和加锁时间界于表锁和行锁之间会出现死锁锁定粒度界于表锁和行锁之间,并发度一般

3、各种锁的适用场景

表级锁更适合于以查询为主,只有少量按索引条件更新数据的应用,如Web应用

行级锁则更适合于有大量按索引条件并发更新数据,同时又有并发查询的应用,如一些在线事务处理系统

4、死锁

是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去。

表级锁不会产生死锁。所以解决死锁主要还是针对于最常用的InnoDB。

5、死锁举例分析

在MySQL中,行级锁并不是直接锁记录,而是锁索引。索引分为主键索引和非主键索引两种,如果一条sql语句 *** 作了主键索引,MySQL就会锁定这条主键索引如果一条语句 *** 作了非主键索引,MySQL会先锁定该非主键索引,再锁定相关的主键索引。

在UPDATE、DELETE *** 作时,MySQL不仅锁定WHERE条件扫描过的所有索引记录,而且会锁定相邻的键值,即所谓的next-key locking。

例如,一个表db。tab_test,结构如下:

id:主键

state:状态

time:时间

索引:idx_1(state,time)

出现死锁日志如下:

?***(1) TRANSACTION:

?TRANSACTION 0 677833455, ACTIVE 0 sec, process no 11393, OSthread id 278546 starting index read

?mysql tables in use 1, locked 1

?LOCK WAIT 3 lock struct(s), heap size 320

?MySQL thread id 83, query id 162348740 dcnet03 dcnet Searching rows for update

?update tab_test set state=1064,time=now() where state=1061 and time <date_sub(now(), INTERVAL 30 minute) (任务1的sql语句)

?***(1) WAITING FOR THIS LOCK TO BE GRANTED: (任务1等待的索引记录)

?RECORD LOCKS space id 0 page no 849384 n bits 208 index `PRIMARY` of table `db/tab_test` trx id 0 677833455 _mode X locks rec but not gap waiting

?Record lock, heap no 92 PHYSICAL RECORD: n_fields 11compact formatinfo bits 0

?0: len 8hex 800000000097629casc b 1: len 6hex 00002866eaeeasc (f 2: len 7hex 00000d40040110asc @ 3: len 8hex 80000000000050b2asc P 4: len 8hex 800000000000502aasc P*5: len 8hex 8000000000005426asc T&6: len 8hex 800012412c66d29casc A,f 7: len 23hex 75706c6f6164666972652e636f6d2f6 8616e642e706870asc xxx.com/8: len 8hex 800000000000042basc +9: len 4hex 474bfa2basc GK +10: len 8hex 8000000000004e24asc N$

?*** (2) TRANSACTION:

?TRANSACTION 0 677833454, ACTIVE 0 sec, process no 11397, OS thread id 344086 updating or deleting, thread declared inside InnoDB 499

?mysql tables in use 1, locked 1

?3 lock struct(s), heap size 320, undo log entries 1

?MySQL thread id 84, query id 162348739 dcnet03 dcnet Updating update tab_test set state=1067,time=now () where id in (9921180) (任务2的sql语句)

?*** (2) HOLDS THE LOCK(S): (任务2已获得的锁)

?RECORD LOCKS space id 0 page no 849384 n bits 208 index `PRIMARY` of table `db/tab_test` trx id 0 677833454 lock_mode X locks rec but not gap

?Record lock, heap no 92 PHYSICAL RECORD: n_fields 11compact formatinfo bits 0

?0: len 8hex 800000000097629casc b 1: len 6hex 00002866eaeeasc (f 2: len 7hex 00000d40040110asc @ 3: len 8hex 80000000000050b2asc P 4: len 8hex 800000000000502aasc P*5: len 8hex 8000000000005426asc T&6: len 8hex 800012412c66d29casc A,f 7: len 23hex 75706c6f6164666972652e636f6d2f6 8616e642e706870asc uploadfire.com/hand.php8: len 8hex 800000000000042basc +9: len 4hex 474bfa2basc GK +10: len 8hex 8000000000004e24asc N$

?*** (2) WAITING FOR THIS LOCK TO BE GRANTED: (任务2等待的锁)

?RECORD LOCKS space id 0 page no 843102 n bits 600 index `idx_1` of table `db/tab_test` trx id 0 677833454 lock_mode X locks rec but not gap waiting

?Record lock, heap no 395 PHYSICAL RECORD: n_fields 3compact formatinfo bits 0

?0: len 8hex 8000000000000425asc %1: len 8hex 800012412c66d29casc A,f 2: len 8hex 800000000097629casc b

?*** WE ROLL BACK TRANSACTION (1)

?(回滚了任务1,以解除死锁)

原因分析:

当“update tab_test set state=1064,time=now() where state=1061 and time <date_sub(now(), INTERVAL 30 minute)”执行时,MySQL会使用idx_1索引,因此首先锁定相关的索引记录,因为idx_1是非主键索引,为执行该语句,MySQL还会锁定主键索引。

假设“update tab_test set state=1067,time=now () where id in (9921180)”几乎同时执行时,本语句首先锁定主键索引,由于需要更新state的值,所以还需要锁定idx_1的某些索引记录。

这样第一条语句锁定了idx_1的记录,等待主键索引,而第二条语句则锁定了主键索引记录,而等待idx_1的记录,这样死锁就产生了。

6、解决办法

拆分第一条sql,先查出符合条件的主键值,再按照主键更新记录:

?select id from tab_test where state=1061 and time <date_sub(now(), INTERVAL 30 minute)

?update tab_test state=1064,time=now() where id in(......)

查询死锁进程

采用如下存储过程来查询数据中当前造成死锁的进程。

drop procedure sp_who_lock

go

CREATE procedure sp_who_lock

as

begin

declare @spid int

declare @blk int

declare @count int

declare @index int

declare @lock tinyint

set @lock=0

create table #temp_who_lock

(

id int identity(1,1),

spid int,

blk int

)

if @@error<>0 return @@error

insert into #temp_who_lock(spid,blk)

select 0 ,blocked

from (select * from master..sysprocesses where blocked>0)a

where not exists(select * from master..sysprocesses where a.blocked =spid and blocked>0)

union select spid,blocked from master..sysprocesses where blocked>0

if @@error<>0 return @@error

select @count=count(*),@index=1 from #temp_who_lock

if @@error<>0 return @@error

if @count=0

begin

select '没有阻塞和死锁信息'

return 0

end

while @index<<A href="mailto:=@count">=@count

begin

if exists(select 1 from #temp_who_lock a where id>@index and exists(select 1 from #temp_who_lock where id<<A href="mailto:=@index">=@index and a.blk=spid))

begin

set @lock=1

select @spid=spid,@blk=blk from #temp_who_lock where id=@index

select '引起数据库死锁的是: '+ CAST(@spid AS VARCHAR(10)) + '进程号,其执行的SQL语法如下'

select @spid, @blk

dbcc inputbuffer(@spid)

dbcc inputbuffer(@blk)

end

set @index=@index+1

end

if @lock=0

begin

set @index=1

while @index<<A href="mailto:=@count">=@count

begin

select @spid=spid,@blk=blk from #temp_who_lock where id=@index

if @spid=0

select '引起阻塞的是:'+cast(@blk as varchar(10))+ '进程号,其执行的SQL语法如下'

else

select '进程号SPID:'+ CAST(@spid AS VARCHAR(10))+ '被' + '进程号SPID:'+ CAST(@blk AS VARCHAR(10)) +'阻塞,其当前进程执行的SQL语法如下'

dbcc inputbuffer(@spid)

dbcc inputbuffer(@blk)

set @index=@index+1

end

end

drop table #temp_who_lock

return 0

end

GO

--执行该存储过程

exec sp_who_lock

补充:

一、产生死锁的原因

在SQL Server中,阻塞更多的是产生于实现并发之间的隔离性。为了使得并发连接所做的 *** 作之间的影响到达某一期望值而对资源人为的进行加锁(锁本质其实可以看作是一个标志位)。当一个连接对特定的资源进行 *** 作时,另一个连接同时对同样的资源进行 *** 作就会被阻塞,阻塞是死锁产生的必要条件。

二、如何避免死锁

1.使用事务时,尽量缩短事务的逻辑处理过程,及早提交或回滚事务;

2.设置死锁超时参数为合理范围,如:3分钟-10分种;超过时间,自动放弃本次 *** 作,避免进程悬挂;

3.优化程序,检查并避免死锁现象出现;

4.对所有的脚本和SP都要仔细测试,在正是版本之前;

5.所有的SP都要有错误处理(通过@error);

6.一般不要修改SQL SERVER事务的默认级别。不推荐强行加锁。

三、处理死锁

1、最简单的处理死锁的方法就是重启服务。

2、根据指定的死锁进程ID进行处理

根据第二步查询到的死锁进行,大致分析造成死锁的原因,并通过如下语句释放该死锁进程

kill pid --pid为查询出来的死锁进程号

3、通过存储过程杀掉某个库下面的所有死锁进程和锁

if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[sp_killspid]') and OBJECTPROPERTY(id, N'IsProcedure') = 1)

drop procedure [dbo].[sp_killspid]

GO

create proc sp_killspid

@dbname varchar(200)--要关闭进程的数据库名

as

declare @sql nvarchar(500)

declare @spid nvarchar(20)

declare #tb cursor for

select spid=cast(spid as varchar(20)) from master..sysprocesses where dbid=db_id(@dbname)

open #tb

fetch next from #tb into @spid

while @@fetch_status=0

begin

exec('kill '+@spid)

fetch next from #tb into @spid

end

close #tb

deallocate #tb

go

--使用方法,“db_name”为处理的数据库名称

exec sp_killspid 'db_name'


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/6128648.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-03-15
下一篇 2023-03-15

发表评论

登录后才能评论

评论列表(0条)

保存