什么時候應該使用SQL Server鎖模式
SQL Server鎖模式是提高SQL數據庫性能的關鍵所在，下面就將為您詳細介紹在什么時候使用SQL Server鎖模式提高性能，供您參考。
現在簡單舉例說明一下，我們在什么時候會使用SQL Server鎖模式定提示來提高性能。
1) 指定表鎖
一般地，SQL Server是不大使用表排它鎖的，尤其是對于比較大的表。因為維持一個大的表排它鎖會嚴重影響系統的并發性能。
但是呢，如果在沒有并發操作的情況下，出現很多的PAGE LOCK和EXT LOCK也會在一定程度上影響性能，畢竟鎖的管理還是需要一定的開銷的。所以，在確認沒有并發操作（或者并發操作優先級低）的情況下，我們可以使用TABLOCKX來指定使用表排他鎖。
UPDATE dbo.ShortMessage WITH (TABLOCKX)
SET OtherPartyNumber = u.Username
FROM dbo.UserList u
WHERE u.UserID = dbo.ShortMessage.OtherPartyID
2) 不使用鎖
一般地，在SELECT的時候，是會對資源發出一個共享鎖的。可是在查詢和更新都很頻繁的時候，我們不希望因為互相等待鎖資源而降低性能，而且我們不在乎讀到的數據是不是***的，不在乎臟讀和未提交讀的產生，我們可以指定SELECT不使用鎖
或者是，在大批更新或插入數據時，由于性子急的原因，我想要知道操作進行到什么程度了，而此時由于表排他鎖的存在，使得我不能或者共享鎖來查詢該表，那么我們也可以不使用鎖。
SELECT COUNT(*) FROM dbo.ShortMessage WITH (NOLOCK)
3) 在查詢時使用排他鎖
這個跟性能倒沒有什么關系，但是在一些特殊的情況下有用，比如我們在查詢某些記錄的時候，不希望它被其它進程所查詢，那么我們可以使用排他鎖。
SELECT * FROM dbo.ShortMessage WITH (XLOCK HOLDLOCK)
WHERE OtherPartyID = 1
這里我還使用了一個HOLDLOCK，是為了使這個鎖保持到整個事務的結束
4) 跳過鎖定行
如果在查詢時，某些記錄由于不能獲得共享鎖而導致阻塞，而我們可以不查詢這些行，那么我們可以跳過鎖定行，比如在3)的情況下，其它查詢就可以跳過鎖定行。
SELECT * FROM dbo.ShortMessage WITH (READPAST)
5) 指定使用行級鎖
假如我們需要在一個并發度很高的環境中做一個大規模的查詢，但是我們不希望這個查詢過于影響其它的查詢，而且本查詢的優先級又不高，那么我們可以指定使用行級鎖。
SELECT * FROM dbo.ShortMessage WITH (ROWLOCK)
【編輯推薦】
