這個問題要具體分析：
創(chuàng)新互聯(lián)是一家專業(yè)提供蚌埠企業(yè)網(wǎng)站建設(shè),專注與成都做網(wǎng)站、成都網(wǎng)站設(shè)計(jì)、成都外貿(mào)網(wǎng)站建設(shè)、H5響應(yīng)式網(wǎng)站、小程序制作等業(yè)務(wù)。10年已為蚌埠眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)絡(luò)公司優(yōu)惠進(jìn)行中。
第一，事務(wù)隔離級別基本兩種模式，一種是阻塞式（read committed，repeatable read，serializable）
，一種是非阻塞式(read uncommitted,snapshot)。
默認(rèn)是read committed，這種情況一般在更新表的時(shí)候，如果不使用hint 提示，基本是先對表添加IX鎖，級別不算高，基本和其他鎖兼容，但是repeatable read，serializable 事務(wù)隔離級別就會先對表添加IX鎖，然后向X鎖轉(zhuǎn)化，而X鎖和大多數(shù)鎖都不兼容，容易發(fā)生表阻塞。
第二種隔離級別不會有以上問題，但是又引入了其它的問題。
以上是一種情況。
另外一種就是 鎖升級，一個鎖是96B內(nèi)存，如果太多，sqlserver就會升級為表鎖，一般是5000以上行級鎖就升級為一個表X鎖。
所以適當(dāng)?shù)奈募纸M和表分區(qū) 是有必要的。
其次就是資源互相引用導(dǎo)致事務(wù)長時(shí)間不能釋放，導(dǎo)致真正的死鎖，不過SQL2005以后，這種情況發(fā)生的概率很低。
留個問題你自己去想。
兩個SQL，兩個連接，同時(shí)執(zhí)行。
update A set A.NAME=xxx where A.id=55
update A set A.NAME=xxx where A.id=56, 如果 56 不存在你說會發(fā)生什么情況呢？
你理解錯了！
默認(rèn)sqlserver都是行數(shù)據(jù)鎖定，隔離級別是 read commited 也就是讀取可 提交數(shù)據(jù)。
我給你舉個例子！
SELECT TOP 1000
[ID]
,[DeleteBy]
,[DelDate]
FROM [dbo].[DeleteLog]
顯示結(jié)果
-----------------------------------------------
ID DeleteBy DelDate
1 admin 2008-04-13 00:00:00.000
2 admin 2008-05-04 00:00:00.000
-------------------------------------------------
表數(shù)據(jù)就兩行
然后我做如下操作：
打開 SQL Server Management Studio
輸入：
begin transaction
DELETE FROM [HMS].[dbo].[DeleteLog]
where ID='1'
在另一個窗口中：
SELECT
[ID]
,[DeleteBy]
,[DelDate]
FROM [dbo].[DeleteLog]
where ID=1
你發(fā)現(xiàn) 這一個窗口被阻塞了，
但是查詢
SELECT
[ID]
,[DeleteBy]
,[DelDate]
FROM [dbo].[DeleteLog]
where ID=2
可以正確返回結(jié)果。 這充分證明了，sqlserver默認(rèn)隔離級別是行數(shù)據(jù)鎖定。
然后你此時(shí)在第一個刪除窗口 中輸入
rollback
，記住前面的刪除不執(zhí)行，只執(zhí)行rollback。
此時(shí)看一下查詢
SELECT
[ID]
,[DeleteBy]
,[DelDate]
FROM [dbo].[DeleteLog]
where ID=1
那個窗口的結(jié)果已經(jīng)出來了，阻塞被解除了。
========================================
當(dāng)然了！你執(zhí)行了全表檢索肯定也是被阻塞的，因?yàn)閯h除操作還沒提交啊，檢索數(shù)據(jù)中又包含了你要刪除的數(shù)據(jù)，當(dāng)然被阻塞了。
你的問題出現(xiàn)在哪里了，你應(yīng)該明白了吧！
解決這個問題其實(shí)很簡單，不要長事務(wù)占用。檢索的時(shí)候避開要刪除的數(shù)據(jù)。
當(dāng)然也可以改變隔離級別，sqlserver分為兩類隔離級別，改成非阻塞類就可以。
但是我個人不推薦這么做。改變隔離級別可以如下方式：
set transaction isolation level read uncommitted
begin transaction
DELETE FROM [HMS].[dbo].[DeleteLog]
where ID='1'
這個刪除沒有提交
檢索的時(shí)候
set transaction isolation level read uncommitted
SELECT
[ID]
,[DeleteBy]
,[DelDate]
FROM [dbo].[DeleteLog]
where ID=1
根本不會阻塞。 比較順利，刪除更新也一樣。
這種方式 適合 數(shù)據(jù)量龐大的社交，天文數(shù)據(jù)庫，企業(yè)管理不適合。
可以從側(cè)面看出，你的程序并不優(yōu)良，明白了否？
SQL SERVER里的鎖機(jī)制：
NOLOCK（不加鎖）
此選項(xiàng)被選中時(shí)，SQL Server 在讀取或修改數(shù)據(jù)時(shí)不加任何鎖。 在這種情況下，用戶有可能讀取到未完成事務(wù)（Uncommited Transaction）或回滾(Roll Back)中的數(shù)據(jù), 即所謂的“臟數(shù)據(jù)”。
HOLDLOCK（保持鎖）
此選項(xiàng)被選中時(shí)，SQL Server 會將此共享鎖保持至整個事務(wù)結(jié)束，而不會在途中釋放。 例如，“ SELECT * FROM my_table HOLDLOCK”就要求在整個查詢過程中，保持對表的鎖定，直到查詢完成才釋放鎖定。
UPDLOCK（修改鎖）
此選項(xiàng)被選中時(shí)，SQL Server 在讀取數(shù)據(jù)時(shí)使用修改鎖來代替共享鎖，并將此鎖保持至整個事務(wù)或命令結(jié)束。使用此選項(xiàng)能夠保證多個進(jìn)程能同時(shí)讀取數(shù)據(jù)但只有該進(jìn)程能修改數(shù)據(jù)。
TABLOCK（表鎖）
此選項(xiàng)被選中時(shí)，SQL Server 將在整個表上置共享鎖直至該命令結(jié)束。 這個選項(xiàng)保證其他進(jìn)程只能讀取而不能修改數(shù)據(jù)。
PAGLOCK（頁鎖）
此選項(xiàng)為默認(rèn)選項(xiàng)， 當(dāng)被選中時(shí)，SQL Server 使用共享頁鎖。
TABLOCKX（排它表鎖）
此選項(xiàng)被選中時(shí)，SQL Server 將在整個表上置排它鎖直至該命令或事務(wù)結(jié)束。這將防止其他進(jìn)程讀取或修改表中的數(shù)據(jù)。
重慶分公司
重慶分公司
