㈠ MSsql事務死鎖的問題
死鎖 發生在 2個 會話， 互相鎖定對方資源的情況下。
例如你的 一個事務X，事務當中有DELETE表A的命令 ， 完成 DELETE A 之後， 又執行 UPDATE B
而另外有一個事務Y, 事務時 先 UPDATE B , 然後 DELETE A.
那麼這種情況下， 可能會發生死鎖。
如果大家都是 DELETE A ， 沒有其他額外操作的話。
那麼 第一個 線程， 執行 DELETE A 的過程中， 後續的線程， 會卡一下， 等待 第一個線程執行完畢。 然後再接著執行。 而不是死鎖。
㈡ sql死鎖的原因及解決方法
在事務中在修改A表的時候沒有結束事務又要讀取A表的數據。導致自己等自己。變成死鎖。
解決方法很簡單，KILL掉就行。
程序上要先selet後update或者insert
㈢ 如何處理SQL Server死鎖問題
死鎖，簡而言之，兩個或者多個trans，同時請求對方正在請求的某個對象，導致雙方互相等待。簡單的例子如下：
trans1 trans2
------------------------------------------------------------------------
1.IDBConnection.BeginTransaction 1.IDBConnection.BeginTransaction
2.update table A 2.update table B
3.update table B 3.update table A
4.IDBConnection.Commit 4.IDBConnection.Commit
那麼，很容易看到，如果trans1和trans2，分別到達了step3，那麼trans1會請求對於B的X鎖，trans2會請求對於A的X鎖，而二者的鎖在step2上已經被對方分別持有了。由於得不到鎖，後面的Commit無法執行，這樣雙方開始死鎖。
好，我們看一個簡單的例子，來解釋一下，應該如何解決死鎖問題。
-- Batch #1
CREATE DATABASE deadlocktest
GO
USE deadlocktest
SET NOCOUNT ON
DBCC TRACEON (1222, -1)
-- 在SQL2005中，增加了一個新的dbcc參數，就是1222，原來在2000下，我們知道，可以執行dbcc
--traceon(1204,3605,-1)看到所有的死鎖信息。SqlServer 2005中，對於1204進行了增強，這就是1222。
GO
IF OBJECT_ID ('t1') IS NOT NULL DROP TABLE t1
IF OBJECT_ID ('p1') IS NOT NULL DROP PROC p1
IF OBJECT_ID ('p2') IS NOT NULL DROP PROC p2
GO
CREATE TABLE t1 (c1 int, c2 int, c3 int, c4 char(5000))
GO
DECLARE @x int
SET @x = 1
WHILE (@x <= 1000) BEGIN
INSERT INTO t1 VALUES (@x*2, @x*2, @x*2, @x*2)
SET @x = @x + 1
END
GO
CREATE CLUSTERED INDEX cidx ON t1 (c1)
CREATE NONCLUSTERED INDEX idx1 ON t1 (c2)
GO
CREATE PROC p1 @p1 int AS SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1
GO
CREATE PROC p2 @p1 int AS
UPDATE t1 SET c2 = c2+1 WHERE c1 = @p1
UPDATE t1 SET c2 = c2-1 WHERE c1 = @p1
GO
上述sql創建一個deadlock的示範資料庫，插入了1000條數據，並在表t1上建立了c1列的聚集索引，和c2列的非聚集索引。另外創建了兩個sp，分別是從t1中select數據和update數據。
好，打開一個新的查詢窗口，我們開始執行下面的query：
-- Batch #2
USE deadlocktest
SET NOCOUNT ON
WHILE (1=1) EXEC p2 4
GO
開始執行後，然後我們打開第三個查詢窗口，執行下面的query：
-- Batch #3
USE deadlocktest
SET NOCOUNT ON
CREATE TABLE #t1 (c2 int, c3 int)
GO
WHILE (1=1) BEGIN
INSERT INTO #t1 EXEC p1 4
TRUNCATE TABLE #t1
END
GO
開始執行，哈哈，很快，我們看到了這樣的錯誤信息：
Msg 1205, Level 13, State 51, Procere p1, Line 4
Transaction (Process ID 54) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
spid54發現了死鎖。
那麼，我們該如何解決它？
在SqlServer 2005中，我們可以這么做：
1.在trans3的窗口中，選擇EXEC p1 4，然後right click，看到了菜單了嗎？選擇Analyse Query in Database Engine Tuning Advisor。
2.注意右面的窗口中，wordload有三個選擇：負載文件、表、查詢語句，因為我們選擇了查詢語句的方式，所以就不需要修改這個radio option了。
3.點左上角的Start Analysis按鈕
4.抽根煙，回來後看結果吧！出現了一個分析結果窗口，其中，在Index Recommendations中，我們發現了一條信息：大意是，在表t1上增加一個非聚集索引索引：t2+t1。
5.在當前窗口的上方菜單上，選擇Action菜單，選擇Apply Recommendations，系統會自動創建這個索引。
重新運行batch #3，呵呵，死鎖沒有了。
這種方式，我們可以解決大部分的Sql Server死鎖問題。那麼，發生這個死鎖的根本原因是什麼呢？為什麼增加一個non clustered index，問題就解決了呢？ 這次，我們分析一下，為什麼會死鎖呢？再回顧一下兩個sp的寫法：
CREATE PROC p1 @p1 int AS
SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1
GO
CREATE PROC p2 @p1 int AS
UPDATE t1 SET c2 = c2+1 WHERE c1 = @p1
UPDATE t1 SET c2 = c2-1 WHERE c1 = @p1
GO
很奇怪吧！p1沒有insert，沒有delete，沒有update，只是一個select，p2才是update。這個和我們前面說過的，trans1裡面updata A，update B；trans2裡面upate B，update A，根本不貼邊啊！
那麼，什麼導致了死鎖？
需要從事件日誌中，看sql的死鎖信息：
Spid X is running this query (line 2 of proc [p1], inputbuffer 「… EXEC p1 4 …」):
SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1
Spid Y is running this query (line 2 of proc [p2], inputbuffer 「EXEC p2 4」):
UPDATE t1 SET c2 = c2+1 WHERE c1 = @p1
The SELECT is waiting for a Shared KEY lock on index t1.cidx. The UPDATE holds a conflicting X lock.
The UPDATE is waiting for an eXclusive KEY lock on index t1.idx1. The SELECT holds a conflicting S lock.
首先，我們看看p1的執行計劃。怎麼看呢？可以執行set statistics profile on，這句就可以了。下面是p1的執行計劃
SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1
|--Nested Loops(Inner Join, OUTER REFERENCES:([Uniq1002], [t1].[c1]))
|--Index Seek(OBJECT:([t1].[idx1]), SEEK:([t1].[c2] >= [@p1] AND [t1].[c2] <= [@p1]+(1)) ORDERED FORWARD)
|--Clustered Index Seek(OBJECT:([t1].[cidx]), SEEK:([t1].[c1]=[t1].[c1] AND [Uniq1002]=[Uniq1002]) LOOKUP ORDERED FORWARD)
我們看到了一個nested loops，第一行，利用索引t1.c2來進行seek，seek出來的那個rowid，在第二行中，用來通過聚集索引來查找整行的數據。這是什麼？就是bookmark lookup啊！為什麼？因為我們需要的c2、c3不能完全的被索引t1.c1帶出來，所以需要書簽查找。
好，我們接著看p2的執行計劃。
UPDATE t1 SET c2 = c2+1 WHERE c1 = @p1
|--Clustered Index Update(OBJECT:([t1].[cidx]), OBJECT:([t1].[idx1]), SET:([t1].[c2] = [Expr1004]))
|--Compute Scalar(DEFINE:([Expr1013]=[Expr1013]))
|--Compute Scalar(DEFINE:([Expr1004]=[t1].[c2]+(1), [Expr1013]=CASE WHEN CASE WHEN ...
|--Top(ROWCOUNT est 0)
|--Clustered Index Seek(OBJECT:([t1].[cidx]), SEEK:([t1].[c1]=[@p1]) ORDERED FORWARD)
通過聚集索引的seek找到了一行，然後開始更新。這里注意的是，update的時候，它會申請一個針對clustered index的X鎖的。
實際上到這里，我們就明白了為什麼update會對select產生死鎖。update的時候，會申請一個針對clustered index的X鎖，這樣就阻塞住了（注意，不是死鎖！）select裡面最後的那個clustered index seek。死鎖的另一半在哪裡呢？注意我們的select語句，c2存在於索引idx1中，c1是一個聚集索引cidx。問題就在這里！我們在p2中更新了c2這個值，所以sqlserver會自動更新包含c2列的非聚集索引：idx1。而idx1在哪裡？就在我們剛才的select語句中。而對這個索引列的更改，意味著索引集合的某個行或者某些行，需要重新排列，而重新排列，需要一個X鎖。
SO………，問題就這樣被發現了。
總結一下，就是說，某個query使用非聚集索引來select數據，那麼它會在非聚集索引上持有一個S鎖。當有一些select的列不在該索引上，它需要根據rowid找到對應的聚集索引的那行，然後找到其他數據。而此時，第二個的查詢中，update正在聚集索引上忙乎：定位、加鎖、修改等。但因為正在修改的某個列，是另外一個非聚集索引的某個列，所以此時，它需要同時更改那個非聚集索引的信息，這就需要在那個非聚集索引上，加第二個X鎖。select開始等待update的X鎖，update開始等待select的S鎖，死鎖，就這樣發生鳥。
那麼，為什麼我們增加了一個非聚集索引，死鎖就消失鳥？我們看一下，按照上文中自動增加的索引之後的執行計劃：
SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1
|--Index Seek(OBJECT:([deadlocktest].[dbo].[t1].[_dta_index_t1_7_2073058421__K2_K1_3]), SEEK:([deadlocktest].[dbo].[t1].[c2] >= [@p1] AND [deadlocktest].[dbo].[t1].[c2] <= [@p1]+(1)) ORDERED FORWARD)
哦，對於clustered index的需求沒有了，因為增加的覆蓋索引已經足夠把所有的信息都select出來。就這么簡單。
實際上，在sqlserver 2005中，如果用profiler來抓eventid：1222，那麼會出現一個死鎖的圖，很直觀的說。
下面的方法，有助於將死鎖減至最少（詳細情況，請看SQLServer聯機幫助，搜索：將死鎖減至最少即可。
按同一順序訪問對象。
避免事務中的用戶交互。
保持事務簡短並處於一個批處理中。
使用較低的隔離級別。
使用基於行版本控制的隔離級別。
將 READ_COMMITTED_SNAPSHOT 資料庫選項設置為 ON，使得已提交讀事務使用行版本控制。
使用快照隔離。
使用綁定連接。
㈣ sql server死鎖的進程怎麼處理
怎麼解除SQL Server死鎖的問題?SQL Server死鎖是我們經常會碰到的問題,下面就為您介紹如何查詢SQL Server死鎖,希望對您學習SQL Server死鎖方面能有所幫助。
SQL Server死鎖的查詢方法: exec master.dbo.p_lockinfo 0,0 ---顯示死鎖的進程,不顯示正常的進程 exec master.dbo.p_lockinfo 1,0 ---殺死死鎖的進程,不顯示正常的進程.
SQL Server死鎖的解除方法: Create proc p_lockinfo @kill_lock_spid bit=1, --是否殺掉死鎖的進程,1 殺掉, 0 僅顯示 @show_spid_if_nolock bit=1 --如果沒有死鎖的進程,是否顯示正常進程信息,1 顯示,0 不顯示 as declare @count int,@s nvarchar(1000),@i int select id=identity(int,1,1),標志, 進程ID=spid,線程ID=kpid,塊進程ID=blocked,資料庫ID=dbid,
資料庫名=db_name(dbid),用戶ID=uid,用戶名=loginame,累計CPU時間=cpu, 登陸時間=login_time,打開事務數=open_tran, 進程狀態=status, 工作站名=hostname,應用程序名=program_name,工作站進程ID=hostprocess, 域名=nt_domain,網卡地址=net_address into #t from( select 標志='死鎖的進程', spid,kpid,a.blocked,dbid,uid,loginame,cpu,login_time,open_tran, status,hostname,program_name,hostprocess,nt_domain,net_address,
s1=a.spid,s2=0 from mastersysprocesses a join ( select blocked from mastersysprocesses group by blocked )b on a.spid=b.blocked where a.blocked=0 union all select '|_犧牲品_>', spid,kpid,blocked,dbid,uid,loginame,cpu,login_time,open_tran, status,hostname,program_name,hostprocess,nt_domain,net_address, s1=blocked,s2=1 from mastersysprocesses a where blocked<>0 )a order by s1,s2 select @count=@@rowcount,@i=1 if @count=0 and @show_spid_if_nolock=1 begin insert #t select 標志='正常的進程', spid,kpid,blocked,dbid,db_name(dbid),uid,loginame,cpu,login_time, open_tran,status,hostname,program_name,hostprocess,nt_domain,net_address from mastersysprocesses set @count=@@rowcount end if @count>0 begin create table #t1(id int identity(1,1),a nvarchar(30),b Int,EventInfo nvarchar(255)) if @kill_lock_spid=1 begin declare @spid varchar(10),@標志 varchar(10) while @i<=@ count begin select @spid=進程ID,@標志=標志 from #t whereid=@ i insert #t1 exec('dbcc inputbuffer(')') if @標志='死鎖的進程' exec('kill'+@ spid) set @i=@i+1 end end else while @i<=@ count begin select @s='dbcc inputbuffer('+cast(進程ID as varchar)+')' from #t whereid=@ i insert #t1 exec(@s) set @i=@i+1 end select a.*,進程的SQL語句=b.EventInfo from #t a join #t1 b on a.id=b.id end
㈤ 怎麼查看和處理SQL死鎖
找到事務號，可以從 events_statements_current 找到對應的 SQL 語句：
SQL_TEXT: delete from action1 where id = 3 //具體的sql語句
DIGEST:
DIGEST_TEXT: DELETE FROM `action1` WHERE `id` = ?
CURRENT_SCHEMA: test1
OBJECT_TYPE: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
OBJECT_INSTANCE_BEGIN: NULL
MYSQL_ERRNO: 0
RETURNED_SQLSTATE: 00000
MESSAGE_TEXT: NULL
ERRORS: 0
WARNINGS: 0
ROWS_AFFECTED: 1
ROWS_SENT: 0
ROWS_EXAMINED: 3
CREATED_TMP_DISK_TABLES: 0
CREATED_TMP_TABLES: 0
SELECT_FULL_JOIN: 0
SELECT_FULL_RANGE_JOIN: 0
SELECT_RANGE: 0
SELECT_RANGE_CHECK: 0
SELECT_SCAN: 0
SORT_MERGE_PASSES: 0
SORT_RANGE: 0
SORT_ROWS: 0
SORT_SCAN: 0
NO_INDEX_USED: 0
NO_GOOD_INDEX_USED: 0
NESTING_EVENT_ID: NULL
NESTING_EVENT_TYPE: NULL
NESTING_EVENT_LEVEL: 0
1 row in set (0.00 sec)
可以看到是一條 delete 阻塞了後續的 update，生產環境中可以拿著這條 SQL 語句詢問開發，是不是有 kill 的必要。
㈥ sql提示死鎖
我也曾遇到過這個問題，記得當時我寫了一個復雜的存儲過程，裡面處理了很多個數據表的數據，且在存儲過程中使用了事務。
該存儲過程在查詢分析器中執行需要20秒左右的時間。但到程序中去執行，所需要的時間就要長很多了。而且由於採用事務，容易產生死鎖。問題與你的一樣。
後來我採取了以下措施，問題便得到改狀況，至目前為止沒有再出現過此問題：
將你的存儲過程進行優化，將需要的數據取到存儲中，使用臨時表或變數保存，而對於插入數據、刪除數據、修改數據、等需要事務的地方，則開啟事務，在此之前的處理中，不要使用事務。
另外就是盡量減少對大數據量表的操作次數，優化各句話，使其執行時間快，效率優。盡量降低存儲過程的運行時間。減少數據表在事務中鎖定的時間。
祝你成功
㈦ sql server 事務造成死鎖怎麼辦
解鎖唄
USE [master]
DECLARE @cmdKill VARCHAR(50)
DECLARE killCursor CURSOR FOR
SELECT 'KILL ' + Convert(VARCHAR(5), p.spid)
FROM master.dbo.sysprocesses AS p
WHERE p.dbid = db_id('auth_ldjt')
OPEN killCursor
FETCH killCursor INTO @cmdKill
WHILE 0 = @@fetch_status
BEGIN
EXECUTE (@cmdKill)
FETCH killCursor INTO @cmdKill
END
CLOSE killCursor
DEALLOCATE killCursor
㈧ sql 事務死鎖
解鎖唄
USE [master]
DECLARE @cmdKill VARCHAR(50)
DECLARE killCursor CURSOR FOR
SELECT 'KILL ' + Convert(VARCHAR(5), p.spid)
FROM master.dbo.sysprocesses AS p
WHERE p.dbid = db_id('auth_ldjt')
OPEN killCursor
FETCH killCursor INTO @cmdKill
WHILE 0 = @@fetch_status
BEGIN
EXECUTE (@cmdKill)
FETCH killCursor INTO @cmdKill
END
CLOSE killCursor
DEALLOCATE killCursor
㈨ 用sql語句，怎麼解決mysql資料庫死鎖
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 11; compact format; info bits 0
?0: len 8; hex 800000000097629c; asc b ;; 1: len 6; hex 00002866eaee; asc (f ;; 2: len 7; hex 00000d40040110; asc @ ;; 3: len 8; hex 80000000000050b2; asc P ;; 4: len 8; hex 800000000000502a; asc P*;; 5: len 8; hex 8000000000005426; asc T&;; 6: len 8; hex 800012412c66d29c; asc A,f ;; 7: len 23; hex 8616e642e706870; asc xxx.com/;; 8: len 8; hex 800000000000042b; asc +;; 9: len 4; hex 474bfa2b; asc GK +;; 10: len 8; hex 8000000000004e24; asc 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 11; compact format; info bits 0
?0: len 8; hex 800000000097629c; asc b ;; 1: len 6; hex 00002866eaee; asc (f ;; 2: len 7; hex 00000d40040110; asc @ ;; 3: len 8; hex 80000000000050b2; asc P ;; 4: len 8; hex 800000000000502a; asc P*;; 5: len 8; hex 8000000000005426; asc T&;; 6: len 8; hex 800012412c66d29c; asc A,f ;; 7: len 23; hex 8616e642e706870; asc uploadfire.com/hand.php;; 8: len 8; hex 800000000000042b; asc +;; 9: len 4; hex 474bfa2b; asc GK +;; 10: len 8; hex 8000000000004e24; asc 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 3; compact format; info bits 0
?0: len 8; hex 8000000000000425; asc %;; 1: len 8; hex 800012412c66d29c; asc A,f ;; 2: len 8; hex 800000000097629c; asc 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(......);