我先把流程說出來，，比如修改一個記錄：
當用戶點修改時，從數據庫讀出數據并顯示到編輯菜單中，然后再編輯數據，再點確定保存到數據庫中。如果多 個用戶，當A用戶點修改到保存該數據這一時間段，，B用戶不能修改，，這個好像不能用事務來做吧，，，大家給個解決方案，，但是我覺得還有點矛盾。當這一 時間段用戶能修改，那么對于A用戶來說數據就已經不一致了，A用戶看到的是B用戶沒有修改前的數據，如果不能修改，也不現實，，如果B用戶點了修改還沒點 確定，，然后用戶出去辦急事或WC，，那A用戶不是一直等，，，
網上經常舉賣車票的例子，當售票員A聽到買票人后開始查詢，發現有2張，，買票人 正好要2張，，在查詢和售出這一時間段，如果其它窗口不能賣，，好像不太現實，，有時這一時間段還是很長的，，一分鐘左右吧，，其它10多個窗口窗口不能 賣這一車次的不是很要命，并且每個窗口都會差不多占一車次的查詢，，如果在查詢到確定出售這一價段其它窗口可以賣，，也出現問題了，，售票員A查詢發現剩 兩張，，告訴買票的人，正好剩兩張，，這時客戶確定要，如果在這一時間段，其它窗口賣一張，，那在確定賣出去時將會失敗，難道要跟買票人解釋。，，這問題 其它也困我很久了，，謝謝大家給我一個解決方案，，也許是我想錯了，，在線等。

技術：

SQL的鎖機制

一. 為什么要引入鎖

多個用戶同時對數據庫的并發操作時會帶來以下數據不一致的問題:

丟失更新
A,B兩個用戶讀同一數據并進行修改,其中一個用戶的修改結果破壞了另一個修改的結果,比如訂票系統

臟讀
A用戶修改了數據,隨后B用戶又讀出該數據,但A用戶因為某些原因取消了對數據的修改,數據恢復原值,此時B得到的數據就與數據庫內的數據產生了不一致

不可重復讀
A用戶讀取數據,隨后B用戶讀出該數據并修改,此時A用戶再讀取數據時發現前后兩次的值不一致

并發控制的主要方法是封鎖,鎖就是在一段時間內禁止用戶做某些操作以避免產生數據不一致

二 鎖的分類

鎖的類別有兩種分法：
1. 從數據庫系統的角度來看：分為獨占鎖（即排它鎖），共享鎖和更新鎖

MS-SQL Server 使用以下資源鎖模式。

鎖模式 描述?
共享 (S) 用于不更改或不更新數據的操作（只讀操作），如 SELECT 語句。?
更新 (U) 用于可更新的資源中。防止當多個會話在讀取、鎖定以及隨后可能進行的資源更新時發生常見形式的死鎖。?
排它 (X) 用于數據修改操作，例如 INSERT、UPDATE 或 DELETE。確保不會同時同一資源進行多重更新。?
意向鎖 用于建立鎖的層次結構。意向鎖的類型為：意向共享 (IS)、意向排它 (IX) 以及與意向排它共享 (SIX)。?
架構鎖 在執行依賴于表架構的操作時使用。架構鎖的類型為：架構修改 (Sch-M) 和架構穩定性 (Sch-S)。?
大容量更新 (BU) 向表中大容量復制數據并指定了 TABLOCK 提示時使用。?

共享鎖
共 享 (S) 鎖允許并發事務讀取 (SELECT) 一個資源。資源上存在共享 (S) 鎖時，任何其它事務都不能修改數據。一旦已經讀取數據，便立即釋放資源上的共享 (S) 鎖，除非將事務隔離級別設置為可重復讀或更高級別，或者在事務生存周期內用鎖定提示保留共享 (S) 鎖。
更新鎖
更新 (U) 鎖可以防止通常形式的死鎖。一般更新模式由一個事務組成，此事務讀取記錄，獲取資源（頁或行）的共享 (S) 鎖，然后修改行，此操作要求鎖轉換為排它 (X) 鎖。如果兩個事務獲得了資源上的共享模式鎖，然后試圖同時更新數據，則一個事務嘗試將鎖轉換為排它 (X) 鎖。共享模式到排它鎖的轉換必須等待一段時間，因為一個事務的排它鎖與其它事務的共享模式鎖不兼容；發生鎖等待。第二個事務試圖獲取排它 (X) 鎖以進行更新。由于兩個事務都要轉換為排它 (X) 鎖，并且每個事務都等待另一個事務釋放共享模式鎖，因此發生死鎖。

若要避免這種潛在的死鎖問題，請使用更新 (U) 鎖。一次只有一個事務可以獲得資源的更新 (U) 鎖。如果事務修改資源，則更新 (U) 鎖轉換為排它 (X) 鎖。否則，鎖轉換為共享鎖。

排它鎖
排它 (X) 鎖可以防止并發事務對資源進行訪問。其它事務不能讀取或修改排它 (X) 鎖鎖定的數據。

意向鎖
意 向鎖表示 SQL Server 需要在層次結構中的某些底層資源上獲取共享 (S) 鎖或排它 (X) 鎖。例如，放置在表級的共享意向鎖表示事務打算在表中的頁或行上放置共享 (S) 鎖。在表級設置意向鎖可防止另一個事務隨后在包含那一頁的表上獲取排它 (X) 鎖。意向鎖可以提高性能，因為 SQL Server 僅在表級檢查意向鎖來確定事務是否可以安全地獲取該表上的鎖。而無須檢查表中的每行或每頁上的鎖以確定事務是否可以鎖定整個表。

意向鎖包括意向共享 (IS)、意向排它 (IX) 以及與意向排它共享 (SIX)。

鎖模式 描述?
意向共享 (IS) 通過在各資源上放置 S 鎖，表明事務的意向是讀取層次結構中的部分（而不是全部）底層資源。?
意向排它 (IX) 通過在各資源上放置 X 鎖，表明事務的意向是修改層次結構中的部分（而不是全部）底層資源。IX 是 IS 的超集。?
與 意向排它共享 (SIX) 通過在各資源上放置 IX 鎖，表明事務的意向是讀取層次結構中的全部底層資源并修改部分（而不是全部）底層資源。允許頂層資源上的并發 IS 鎖。例如，表的 SIX 鎖在表上放置一個 SIX 鎖（允許并發 IS 鎖），在當前所修改頁上放置 IX 鎖（在已修改行上放置 X 鎖）。雖然每個資源在一段時間內只能有一個 SIX 鎖，以防止其它事務對資源進行更新，但是其它事務可以通過獲取表級的 IS 鎖來讀取層次結構中的底層資源。?

獨占鎖：只允許進行鎖定操作的程序使用，其他任何對他的操作均不會被接受。執行數據更新命令時，SQL Server會自動使用獨占鎖。當對象上有其他鎖存在時，無法對其加獨占鎖。
共享鎖：共享鎖鎖定的資源可以被其他用戶讀取，但其他用戶無法修改它，在執行Select時，SQL Server會對對象加共享鎖。
更新鎖：當SQL Server準備更新數據時，它首先對數據對象作更新鎖鎖定，這樣數據將不能被修改，但可以讀取。等到SQL Server確定要進行更新數據操作時，他會自動將更新鎖換為獨占鎖，當對象上有其他鎖存在時，無法對其加更新鎖。
2. 從程序員的角度看：分為樂觀鎖和悲觀鎖。
樂觀鎖：完全依靠數據庫來管理鎖的工作。
悲觀鎖：程序員自己管理數據或對象上的鎖處理。

MS-SQLSERVER 使用鎖在多個同時在數據庫內執行修改的用戶間實現悲觀并發控制


三 鎖的粒度
? 鎖粒度是被封鎖目標的大小,封鎖粒度小則并發性高,但開銷大,封鎖粒度大則并發性低但開銷小

SQL Server支持的鎖粒度可以分為為行、頁、鍵、鍵范圍、索引、表或數據庫獲取鎖

資源 描述?
RID 行標識符。用于單獨鎖定表中的一行。?
鍵 索引中的行鎖。用于保護可串行事務中的鍵范圍。?
頁 8 千字節 (KB) 的數據頁或索引頁。?
擴展盤區 相鄰的八個數據頁或索引頁構成的一組。?
表 包括所有數據和索引在內的整個表。?
DB 數據庫。?


四 鎖定時間的長短

鎖保持的時間長度為保護所請求級別上的資源所需的時間長度。?

用 于保護讀取操作的共享鎖的保持時間取決于事務隔離級別。采用 READ COMMITTED 的默認事務隔離級別時，只在讀取頁的期間內控制共享鎖。在掃描中，直到在掃描內的下一頁上獲取鎖時才釋放鎖。如果指定 HOLDLOCK 提示或者將事務隔離級別設置為 REPEATABLE READ 或 SERIALIZABLE，則直到事務結束才釋放鎖。

根據為游標設置的并發選項，游標可以獲取共享模式的滾動鎖以保護提取。當需要滾動鎖時，直到下一次提取或關閉游標（以先發生者為準）時才釋放滾動鎖。但是，如果指定 HOLDLOCK，則直到事務結束才釋放滾動鎖。

用于保護更新的排它鎖將直到事務結束才釋放。?
如果一個連接試圖獲取一個鎖，而該鎖與另一個連接所控制的鎖沖突，則試圖獲取鎖的連接將一直阻塞到：?

將沖突鎖釋放而且連接獲取了所請求的鎖。

連接的超時間隔已到期。默認情況下沒有超時間隔，但是一些應用程序設置超時間隔以防止無限期等待?

2003-6-10 11:08:00 ?
查看評語??? 2003-6-10 11:10:02 ?
五 SQL Server 中鎖的自定義?

1 處理死鎖和設置死鎖優先級

死鎖就是多個用戶申請不同封鎖,由于申請者均擁有一部分封鎖權而又等待其他用戶擁有的部分封鎖而引起的無休止的等待

可以使用SET DEADLOCK_PRIORITY控制在發生死鎖情況時會話的反應方式。如果兩個進程都鎖定數據，并且直到其它進程釋放自己的鎖時，每個進程才能釋放自己的鎖，即發生死鎖情況。

2 處理超時和設置鎖超時持續時間。

@@LOCK_TIMEOUT 返回當前會話的當前鎖超時設置，單位為毫秒

SET LOCK_TIMEOUT 設置允許應用程序設置語句等待阻塞資源的最長時間。當語句等待的時間大于 LOCK_TIMEOUT 設置時，系統將自動取消阻塞的語句，并給應用程序返回"已超過了鎖請求超時時段"的 1222 號錯誤信息

示例?
下例將鎖超時期限設置為 1,800 毫秒。
SET LOCK_TIMEOUT 1800

3) 設置事務隔離級別。
參見 http://expert.csdn.net/Expert/topic/1785/1785314.xml?temp=.3050501

4 ) 對 SELECT、INSERT、UPDATE 和 DELETE 語句使用表級鎖定提示。

5) 配置索引的鎖定粒度
可以使用 sp_indexoption 系統存儲過程來設置用于索引的鎖定粒度

六 查看鎖的信息

1 執行 EXEC SP_LOCK 報告有關鎖的信息
2 查詢分析器中按Ctrl+2可以看到鎖的信息

七 使用注意事項

如何避免死鎖
1 使用事務時，盡量縮短事務的邏輯處理過程，及早提交或回滾事務；
2 設置死鎖超時參數為合理范圍，如：3分鐘-10分種；超過時間，自動放棄本次操作，避免進程懸掛；
3 優化程序，檢查并避免死鎖現象出現；
4 .對所有的腳本和SP都要仔細測試，在正是版本之前。
5 所有的SP都要有錯誤處理（通過@error）
6 一般不要修改SQL SERVER事務的默認級別。不推薦強行加鎖

解決問題 如何對行 表 數據庫加鎖

八 幾個有關鎖的問題

1 如何鎖一個表的某一行

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED?

SELECT * FROM table ROWLOCK WHERE id = 1

2 鎖定數據庫的一個表

SELECT * FROM table WITH (HOLDLOCK)?

加鎖語句：
sybase:
? update 表 set col1=col1 where 1=0 ;
MSSQL:
? select col1 from 表 (tablockx) where 1=0 ;
oracle:
? LOCK TABLE 表 IN EXCLUSIVE MODE ；
加鎖后其它人不可操作，直到加鎖用戶解鎖，用commit或rollback解鎖


幾個例子幫助大家加深印象
設table1(A,B,C)
A B C
a1 b1 c1
a2 b2 c2
a3 b3 c3

1）排它鎖
新建兩個連接
在第一個連接中執行以下語句
begin tran
? update table1
? set A='aa'
? where B='b2'
? waitfor delay '00:00:30' --等待30秒
commit tran
在第二個連接中執行以下語句
begin tran
? select * from table1
? where B='b2' ?
commit tran

若同時執行上述兩個語句，則select查詢必須等待update執行完畢才能執行即要等待30秒

2）共享鎖
在第一個連接中執行以下語句
begin tran
? select * from table1 holdlock -holdlock人為加鎖
? where B='b2'?
? waitfor delay '00:00:30' --等待30秒
commit tran

在第二個連接中執行以下語句
begin tran
? select A,C from table1
? where B='b2'?
? update table1
? set A='aa'
? where B='b2' ?
commit tran

若同時執行上述兩個語句，則第二個連接中的select查詢可以執行
而update必須等待第一個事務釋放共享鎖轉為排它鎖后才能執行 即要等待30秒

3）死鎖
增設table2(D,E)
D E
d1 e1
d2 e2
在第一個連接中執行以下語句
begin tran
? update table1
? set A='aa'
? where B='b2'?
? waitfor delay '00:00:30'
? update table2
? set D='d5'
? where E='e1'?
commit tran
??
在第二個連接中執行以下語句
begin tran
? update table2
? set D='d5'
? where E='e1'?
? waitfor delay '00:00:10'
? update table1
? set A='aa'
? where B='b2' ?
commit tran

同時執行，系統會檢測出死鎖，并中止進程

悲觀鎖定解決方案-- 我們只要對上邊的代碼做微小的改變就可以實現悲觀的鎖定.declare@CardNovarchar(20) BeginTran-- 選擇一張未使用的卡selecttop1@CardNo=F_CardNofrom Card with (UPDLOCK) where F_Flag=0-- 延遲50秒，模擬并發訪問.waitfor delay '000:00:50'-- 把剛才選擇出來的卡進行注冊.update Cardset F_Name=user,F_Time=getdate(),F_Flag=1where F_CardNo=@CardNocommit注意其中的區別了嗎?with(updlock),是的,我們在查詢的時候使用了with (UPDLOCK)選項,在查詢記錄的時候我們就對記錄加上了更新鎖
樂觀鎖定解決方案-- 首先我們在Card表里邊加上一列F_TimeStamp 列,該列是varbinary(8)類型.但是在更新的時候這個值會自動增長.altertable Card add F_TimeStamp timestampnotnull-- 悲觀鎖定declare@CardNovarchar(20) declare@timestampvarbinary(8) declare@rowcountintBeginTran-- 取得卡號和原始的時間戳值selecttop1@CardNo=F_CardNo,@timestamp=F_TimeStampfrom Cardwhere F_Flag=0-- 延遲50秒，模擬并發訪問.waitfor delay '000:00:50'-- 注冊卡,但是要比較時間戳是否發生了變化.如果沒有發生變化.更新成功.如果發生變化,更新失敗.update Cardset F_Name=user,F_Time=getdate(),F_Flag=1where F_CardNo=@CardNoand F_TimeStamp=@timestampset@rowcount=@@rowcountif@rowcount=1beginprint'更新成功!'commitendelseif@rowcount=0beginifexists(select1from Card where F_CardNo=@CardNo)beginprint'此卡已經被另外一個用戶注冊！'rollbacktranendelsebeginprint'并不存在此卡!'rollbacktranendend在另外一個窗口里邊執行沒有waitfor的代碼,注冊成功后,返回原來的窗口,我們就會發現到時間后它顯示的提示是此卡以被另外一個用戶 參考網站：http://topic.csdn.net/u/20090520/10/d2eac176-afca-4321-9384-45d82a6f010b.html

轉載于:https://www.cnblogs.com/rongxiaoya/archive/2012/09/14/2685524.html

總結

以上是生活随笔為你收集整理的[转]关于数据库的并发性的一个解决方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。