sqlserver database deadlock

--查询死锁 
select 
request_session_id spid,
OBJECT_NAME(resource_associated_entity_id) tableName 
from sys.dm_tran_locks where resource_type='OBJECT' 



--杀死单个死锁
kill spid


--在master中创建删除指定数据库的死锁的存储过程
use master  
go  
  
if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[p_killspid]') and OBJECTPROPERTY(id, N'IsProcedure') = 1)  
drop procedure [dbo].[p_killspid]  
GO  
  
create proc p_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 

--删除该库下的死锁
exec master..p_killspid 'dbname'

avoid deadlock

1. Access objects in the same order

   Deadlocks are less likely to occur if all concurrent transactions access objects in the same order. For example, if two concurrent transactions acquire a lock on the Supplier table and then acquire a lock on the Part table, the other transaction is blocked on the Supplier table until one of them completes. After the first transaction commits or rolls back, the second transaction continues. No deadlock occurs. Using stored procedures for all data modifications can standardize the order in which objects are accessed.

2. Avoid user interaction in transactions

   Avoid writing transactions that include user interaction, because running batches without user interaction is much faster than a user can manually respond to a query, such as a prompt for replying to application request parameters. For example, if a transaction is waiting for user input, and the user goes to lunch or even goes home for the weekend, the user suspends the transaction so that it cannot be completed. This will reduce the throughput of the system because any locks held by the transaction will only be released when the transaction commits or rolls back. Even if there is no deadlock situation, other transactions accessing the same resource will be blocked waiting for the transaction to complete.

3. Keep transactions short and in one batch

   Deadlocks often occur when multiple long-running transactions are executed concurrently in the same database. The longer a transaction runs, the longer it holds an exclusive or update lock, blocking other activities and potentially causing deadlocks.

   Keeping transactions in a batch minimizes network round-trips for transactions, reduces possible delays in completing transactions, and releases locks.

4. Use a low isolation level

   Determines whether a transaction can run at a lower isolation level. Performing a committed read allows a transaction to read data that has been read (unmodified) by another transaction without having to wait for the first transaction to complete. Using a lower isolation level (such as committed read) instead of a higher isolation level (such as serializable read) can reduce the time that shared locks are held, thereby reducing lock contention.

   1. ALTER DATABASE [dbname]  
   2. SET READ_COMMITTED_SNAPSHOT ON  

use bind connection

Using bonded connections enables two or more connections opened by the same application to cooperate with each other. Any locks acquired by the secondary connection can be held like locks acquired by the primary connection and vice versa, and thus do not block each other.