mysql 查看表 是否有死锁
1、查询是否锁表
创新互联提供高防物理服务器租用、云服务器、香港服务器、西信服务器托管等
show OPEN TABLES where In_use 0;
2、查询进程
show processlist
查询到相对应的进程===然后 kill id
补充:
查看正在锁的事务
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;
查看等待锁的事务
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;
如何查询mysql中是否表被锁
可直接在mysql命令行执行:show engine innodb status\G;
查看造成死锁的sql语句,分析索引情况,然后优化sql然后show processlist;
另外可以打开慢查询日志,linux下打开需在my.cnf的[mysqld]里面加上以下内容:
如何查mysql死锁进程
查询死锁进程
采用如下存储过程来查询数据中当前造成死锁的进程。
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 @@error0 return @@error
insert into #temp_who_lock(spid,blk)
select 0 ,blocked
from (select * from master..sysprocesses where blocked0)a
where not exists(select * from master..sysprocesses where a.blocked =spid and blocked0)
union select spid,blocked from master..sysprocesses where blocked0
if @@error0 return @@error
select @count=count(*),@index=1 from #temp_who_lock
if @@error0 return @@error
if @count=0
begin
select '没有阻塞和死锁信息'
return 0
end
while @indexA 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 idA 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 @indexA 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'
有人知道mysql 只要查询就会锁表是什么原因吗?
你确定是select引起的??看看日志..看看状态...还有你的引擎是什么? innodb么? 你的锁机制又是什么?
如何查看MySQL数据库的死锁信息
查看MySQL数据库的死锁日志
1. 使用终端或命令提示符登录到MySQL,输入命令:mysql -h xxxx.xxx.xxx -P 3306 -u username -p 解释:xxxx.xxx.xxx是数据库IP地址,username是数据库用户名,输入命令后,会让你输入username对应的密码,就可以登录了
2. 如何查看MySQL数据库的死锁信息 在MySQL客户端下输入命令: show engine innodb status \G;
3. 如何定位MySQL数据库的死锁信息 在打印出来的信息中找到“LATEST DETECTED DEADLOCK”一节内容,看图中红线
4. 如何分析日志,定位死锁原因 看3里面的图,紫色划线部分 分析: 事务1,等待 RECORD LOCKS space id 553 page no 376 n bits 368 index `index_user_id` of table `tbj`.`score_user`,这个位置的X锁 事务2,持有 RECORD LOCKS space id 553 page no 376 n bits 368 index `index_user_id` of table `tbj`.`score_user`这个地方的S锁 事务2,等待这个地方的X锁 理论上这个事务2是可以提交的不会,死锁,但是这个事务日志只打印最后一部分死锁,信息,这里面隐含的条件是,事务1也持有 RECORD LOCKS space id 553 page no 376 n bits 368 index `index_user_id` of table `tbj`.`score_user`这个地方的S锁,这样,事务2不能加X锁,同时事务1也不能加X锁,产生死锁。
文章标题:mysql怎么查表被锁了 mysql如何查询表是否被锁
URL网址:http://lswzjz.com/article/doojgdh.html