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(......);
『貳』 SQL Server表鎖定原理以及如何解除鎖定
SELECT resource_type, request_mode, resource_description WHERE resource_type 'DATABASE' order by request_modeROLLBACK TRAN 6. Bulk Update locks (BU) 資料庫引擎在將數據大容量復制到表中時使用了大容量更新 (BU) 鎖, 並指定了 TABLOCK 提示或使用 sp_tableoption 設置了 table lock on bulk load 表選項. 大容量更新鎖(BU 鎖)允許多個線程將數據並發地大容量載入到同一表, 同時防止其他不進行大容量載入數據的進程訪問該表. 7. Key - Range locks 在使用可序列化事務隔離級別時, 對於 Transact-SQL 語句讀取的記錄集, 鍵范圍鎖可以隱式保護該記錄集中包含的行范圍. 鍵范圍鎖可防止幻讀. 通過保護行之間鍵的范圍, 它還防止對事務訪問的記錄集進行幻像插入或刪除. 二: 死鎖與死鎖解除 1. 死鎖 使用或管理資料庫都不可避免的涉及到死鎖. 一旦發生死鎖, 數據相互等待對方資源的釋放,會阻止對數據的訪問, 嚴重會造成DB掛掉. 當資源被鎖定, 無法被訪問時, 可以終止訪問DB的那個session來達到解鎖的目的(即 Kill掉造成鎖的那個進程). 在兩個或多個任務中，如果每個任務鎖定了其他任務試圖鎖定的資源，此時會造成這些任務永久阻塞，從而出現死鎖。 例如： 事務A 獲取了行 1 的共享鎖。 事務B 獲取了行 2 的共享鎖。 現在，事務 A 請求行 2 的排他鎖，但在事務 B 完成並釋放其對行 2 持有的共享鎖之前被阻塞。 現在，事務 B 請求行 1 的排他鎖，但在事務 A 完成並釋放其對行 1 持有的共享鎖之前被阻塞。 事務B 完成之後事務 A 才能完成，但是事務 B 由事務 A 阻塞。該條件也稱為循環依賴關系： 事務 A 依賴於事務 B，事務 B 通過對事務 A 的依賴關系關閉循環。 除非某個外部進程斷開死鎖，否則死鎖中的兩個事務都將無限期等待下去。 Microsoft SQL Server 資料庫引擎死鎖監視器定期檢查陷入死鎖的任務。 如果監視器檢測到循環依賴關系，將選擇其中一個任務作為犧牲品，然後終止其事務並提示錯誤。 這樣，其他任務就可以完成其事務。 對於事務以錯誤終止的應用程序，它還可以重試該事務，但通常要等到與它一起陷入死鎖的其他事務完成後執行。 2. 死鎖檢測 2.1 SQL Server 資料庫引擎自動檢測 SQL Server 中的死鎖循環。資料庫引擎選擇一個會話作為死鎖犧牲品，然後終止當前事務(出現錯誤)來打斷死鎖。 2.2 查看DMV: sys.dm_tran_locks 2.3 SQL Server Profiler能夠直觀的顯示死鎖的圖形事件. 三: 鎖兼容性 鎖兼容性控制多個事務能否同時獲取同一資源上的鎖。 如果資源已被另一事務鎖定，則僅當請求鎖的模式與現有鎖的模式相兼容時，才會授予新的鎖請求。 如果請求鎖的模式與現有鎖的模式不兼容，則請求新鎖的事務將等待釋放現有鎖或等待鎖超時間隔過期。 例如，沒有與排他鎖兼容的鎖模式。 如果具有排他鎖(X 鎖)，則在釋放排他鎖(X 鎖)之前，其他事務均無法獲取該資源的任何類型(共享、更新或排他)的鎖。 另一種情況是，如果共享鎖(S 鎖)已應用到資源，則即使第一個事務尚未完成，其他事務也可以獲取該項的共享鎖或更新鎖(U 鎖)。 但是，在釋放共享鎖之前，其他事務無法獲取排他鎖。
『叄』 mysql有一條sql語句導致一直鎖表，怎麼解決
-- 查看那些表鎖到了
show OPEN TABLES where In_use > 0;
-- 查看進程號
show processlist;
--刪除進程
kill 1085850；
『肆』 sqlserver怎麼用sql查看具體那個表被鎖住了
查看被鎖表：
select request_session_id spid,OBJECT_NAME(resource_associated_entity_id) tableName
from sys.dm_tran_locks where resource_type='OBJECT'
--spid 鎖表進程
--tableName 被鎖表名
解鎖：
declare @spid int
Set @spid = 57 --鎖表進程
declare @sql varchar(1000)
set @sql='kill '+cast(@spid as varchar)
exec(@sql)
--查詢出死鎖的SPID
select blocked
from (select * from sysprocesses where blocked>0 ) a
where not exists(select * from (select * from sysprocesses where blocked>0 ) b
where a.blocked=spid)
--輸出引起死鎖的操作
DBCC INPUTBUFFER (@spid)
--查詢當前進程數
select count(-1) from sysprocesses
where dbid in (select dbid from sysdatabases where name like '%telcount%');
『伍』 sql表被鎖了怎麼辦
你可以嘗試重啟SQL服務或重啟資料庫，這樣可以恢復正常。接下來查看日誌，排查被鎖的原因，最後根據情況，處理問題。
『陸』 怎樣用SQL給SQL2880特定表加鎖解鎖
加鎖的語句如下：
SELECT * FROM 表名 WITH (TABLOCK);這里沒有解鎖的概念，只有不加鎖的概念，語句如下：
SELECT * FROM 表名 WITH (NOLOCK);加鎖的解釋：
TABLOCK（表鎖）
此選項被選中時，SQL Server 將在整個表上置
共享鎖
直至該命令結束。 這個選項保證其他進程只能讀取而不能修改數據。
不加鎖的解釋：
NOLOCK（不加鎖）
此選項被選中時，SQL Server 在讀取或修改數據時不加任何鎖。 在這種情況下，用戶有可能讀取到