Ⅰ mysql 使用樂觀鎖時，自帶的悲觀鎖會失效么
這是兩個不同的概念。
1.在表中增加version，是由你自己寫的程序或者sql的where條件控制的，並沒有真正的到達mysql的事務層。
2.悲觀鎖是mysql自己維護的鎖機制，你加不加version跟悲觀鎖沒關系，而只跟你設置的事務級別有關系
Ⅱ 如何在SQLServer中鎖定某行記錄
可以用悲觀鎖和樂觀鎖兩種訪求
（1）悲觀鎖
就像前面所說的那樣使用
例如：
select * from ta with(UPDLOCK)
這樣當記錄已經被鎖定後，
其他的人再試圖再次更新訪問的時候會失敗。
詳細內容不再細述了。
（2）樂觀鎖
類似16樓的說法，比如在表中增加一個欄位以保存最後一次更新的時間戳，
更新的時候，用取得數據時的時間與資料庫中的更新時間進行比較，
如果比資料庫中的最後更新時間早的話，
則說明之前已經有其它人對於數據進行了更新。
則更新不能進行。
可以使用下面的語句進行更新操作。
updata <表名> set ..... where upddate <= <上次取得記錄的更新時間>
Ⅲ mybatis for update </mapper>悲觀鎖sql怎麼寫
mybatis for update </mapper>悲觀鎖sql怎麼寫
import com.github.abel533.mapper.Mapper;@Repository("courseDao")public interface CourseDao extends Mapper<Course>{}
這樣我們就擁有了Mapper中的通用方法
如果是maven項目，在pom文件中添加如下依賴即可：
<!-- 通用Mapper --><dependency> <groupId>com.github.abel533</groupId> <artifactId>mapper</artifactId> <version>2.3.4</version></dependency>
Ⅳ hibernate 悲觀鎖和樂觀鎖只對HQL語句有效嗎
樂觀鎖是一種程序實現，無論用不用hibernate都能實現，與sql和資料庫都沒有關系。
悲觀鎖由sql語句for update標識觸發，是由資料庫支持的，也與hibernate自有技術無關。
hibernate提供了對悲觀鎖的支持，是通過設定參數實現的，本質是為了變更最終發出去的sql寫法，和用不用hql沒有關系。
如果想不明白，還是再去認真了解一下樂觀鎖和悲觀鎖吧
Ⅳ sql server 怎麼保證查詢出的結果不能被其他電腦訪問，具體如下
這涉及到資料庫中,鎖的概念
首先,SQL Server更強調由系統來管理鎖。在用戶有SQL請求時，系統分析請求，自動在滿足鎖定條件和系統性能之間為資料庫加上適當的鎖，同時系統在運行期間常常自動進行優化處理，實行動態加鎖。也就是說,你的擔心是不必要的,SQLServer可以保證這種情況基本不會出現.如果特殊情況下，需要你手動出來，請參考下面文檔。
一. 為什麼要引入鎖
多個用戶同時對資料庫的並發操作時會帶來以下數據不一致的問題:
丟失更新
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，則直到事務結束才釋放滾動鎖。
用於保護更新的排它鎖將直到事務結束才釋放。
如果一個連接試圖獲取一個鎖，而該鎖與另一個連接所控制的鎖沖突，則試圖獲取鎖的連接將一直阻塞到：
將沖突鎖釋放而且連接獲取了所請求的鎖。
連接的超時間隔已到期。默認情況下沒有超時間隔，但是一些應用程序設置超時間隔以防止無限期等待
五 SQL Server 中鎖的自定義
1 處理死鎖和設置死鎖優先順序
死鎖就是多個用戶申請不同封鎖,由於申請者均擁有一部分封鎖權而又等待其他用戶擁有的部分封鎖而引起的無休止的等待
可以使用SET DEADLOCK_PRIORITY控制在發生死鎖情況時會話的反應方式。如果兩個進程都鎖定數據，並且直到其它進程釋放自己的鎖時，每個進程才能釋放自己的鎖，即發生死鎖情況。
2 處理超時和設置鎖超時持續時間。
@@LOCK_TIMEOUT 返回當前會話的當前鎖超時設置，單位為毫秒
SET LOCK_TIMEOUT 設置允許應用程序設置語句等待阻塞資源的最長時間。當語句等待的時間大於 LOCK_TIMEOUT 設置時，系統將自動取消阻塞的語句，並給應用程序返回"已超過了鎖請求超時時段"的 1222 號錯誤信息
示例
下例將鎖超時期限設置為 1,800 毫秒。
SET LOCK_TIMEOUT 1800
3) 設置事務隔離級別。
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
同時執行，系統會檢測出死鎖，並中止進程
補充一點:
Sql Server2000支持的表級鎖定提示
HOLDLOCK 持有共享鎖，直到整個事務完成，應該在被鎖對象不需要時立即釋放，等於SERIALIZABLE事務隔離級別
NOLOCK 語句執行時不發出共享鎖，允許臟讀 ，等於 READ UNCOMMITTED事務隔離級別
PAGLOCK 在使用一個表鎖的地方用多個頁鎖
READPAST 讓sql server跳過任何鎖定行，執行事務，適用於READ UNCOMMITTED事務隔離級別只跳過RID鎖，不跳過頁，區域和表鎖
ROWLOCK 強制使用行鎖
TABLOCKX 強制使用獨占表級鎖，這個鎖在事務期間阻止任何其他事務使用這個表
UPLOCK 強制在讀表時使用更新而不用共享鎖
應用程序鎖:
應用程序鎖就是客戶端代碼生成的鎖，而不是sql server本身生成的鎖
處理應用程序鎖的兩個過程
sp_getapplock 鎖定應用程序資源
sp_releaseapplock 為應用程序資源解鎖
注意: 鎖定資料庫的一個表的區別
SELECT * FROM table WITH (HOLDLOCK) 其他事務可以讀取表，但不能更新刪除
SELECT * FROM table WITH (TABLOCKX) 其他事務不能讀取表,更新和刪除
Ⅵ sql 鎖 的概念
舉個例子吧 當你要進一個房間的時候，你想推門，這個時候剛好有個人想出來，他也想推門出去，於是，兩個人就卡在那了，結果，後面排隊的人也都動彈不了了，假如這個房間是個資料庫，那麼，資料庫這個時候就卡殼了。
鎖正是為避免這種情況出現的
悲觀鎖就是 一個一個來，當有人想進這個房間的時候，其他人都別動
但假如這個房間有很多門，這些門通往不同的地方，比如，有可以直接進洗手間的，有可以進廚房的，結果，你一個人想去卧室，卻禁止其他人進洗手間，這樣對效率就會產生影響。於是，樂觀所就是，當你想進的時候，等到你來到門的門口，才把當前這個門鎖住。之所以叫樂觀，也就是說，樂觀地假定你的行為不會影響到其他人，等到影響到的時候再加鎖。而悲觀的意思，就是一開始就假定你會影響到其他人了，所以全部鎖了干凈。
並不是說樂觀鎖一定好過悲觀鎖。樂觀鎖可能會產生臟數據（具體的書里巴拉巴拉講了一堆，就忘了。。）
恩 大概是這樣啦，具體語法就要自己去搜啦
Ⅶ 悲觀鎖的簡介
一個典型的倚賴資料庫的悲觀鎖調用：
select * from account where name=Erica for update
這條 sql 語句鎖定了 account 表中所有符合檢索條件（ name=Erica ）的記錄。 本次事務提交之前（事務提交時會釋放事務過程中的鎖），外界無法修改這些記錄。
Hibernate 的悲觀鎖，也是基於資料庫的鎖機制實現。
下面的代碼實現了對查詢記錄的加鎖：
String hqlStr = from TUser as user where user.name='Erica';
Query query = session.createQuery(hqlStr);
query.setLockMode(user,LockMode.UPGRADE); // 加鎖
List userList = query.list();// 執行查詢，獲取數據
query.setLockMode 對查詢語句中，特定別名所對應的記錄進行加鎖（我們為TUser 類指定了一個別名user），這里也就是對返回的所有 user 記錄進行加鎖。
觀察運行期 Hibernate 生成的 SQL 語句：
select tuser0_.id as id, tuser0_.name as name, tuser0_.group_id as group_id, tuser0_.user_type as user_type, tuser0_.sex as sex from t_user tuser0_ where (tuser0_.name='Erica' ) for update
這里 Hibernate 通過使用資料庫的 for update 子句實現了悲觀鎖機制。
Hibernate 的加鎖模式有：
Ø LockMode.NONE ： 無鎖機制。
Ø LockMode.WRITE ： Hibernate 在 Insert 和 Update 記錄的時候會自動 獲取。
Ø LockMode.READ ： Hibernate 在讀取記錄的時候會自動獲取。 以上這三種鎖機制一般由 Hibernate 內部使用，如 Hibernate 為了保證 Update過程中對象不會被外界修改，會在 save 方法實現中自動為目標對象加上 WRITE 鎖。
Ø LockMode.UPGRADE ：利用資料庫的 for update 子句加鎖。
Ø LockMode. UPGRADE_NOWAIT ： Oracle 的特定實現，利用 Oracle 的 forupdate nowait 子句實現加鎖。
Ⅷ postgresql 有悲觀鎖和樂觀鎖嗎
資料庫事物單個邏輯單元工作執行的一系列操作，就是一些sql語句，也可以是多條，一個update操作就是一個事物。
事物具有四種特性
1.原子性
事物必須是原子工作單元，要麼都執行成功（也就是說所有的sql語句都執行成功），要麼都不執行（所有的sql語句都不執行）。
2. 一致性
事務在完成時，必須使所有的數據都保持一致狀態。
3.隔離性
允許多個用戶對數據進行並發訪問，而不破環數據的完整行和正確性，同時，並發事物的修改必須與其他並發事物隔離，一般是通過加鎖實現。
4.持久性
事物完成後，數據必須永久的保存到資料庫中。
事物並發訪問如果不設置事物的隔離級別，就會帶來如下問題
1.臟讀 讀取了其他事物未提交的數據，一個事物修改了某條數據還未提交，一個事物讀取了這條數據，而修改的事物由於某種原因失敗會滾了，這個時候讀取事物就讀到了臟數據。
2.不可重復讀
一個事物兩次讀取某條數據，但讀取的結果不一樣，在第二次讀取的時候其他實物修改了這條數據。
3.幻讀
一個事物兩次讀取，讀取到了其他事物插入到數據中的數據。
針對以上情況，資料庫提供了四種事物的隔離級別來解決事物並發帶來的問題。
1.讀未提交（read uncommited）
寫事物會阻塞寫事物，但不會阻塞讀取事物，因此不能解決讀取臟數據，讀取事物不會阻塞其他事物，這中隔離級別不能解決上面任何問題。
2 讀已經提交（read commited）
寫事物會阻塞寫事物和讀取事物，因此可以避免讀取臟數據，但讀取事物不會阻塞寫事物，不能解決可重復度去的問題。
3 可重復讀（Repeatable read）
讀事物會阻塞寫事物和讀事物，因此可以重復讀，但其他事物可以進行插入操作，不能解決幻讀的問題。
4 序列化(Serializable)
事物必須一個一個的執行 ，可以解決上面的問題，但事物基本沒有並發性。
事物的並發控制
當多個人並發修改同一條數據時，必須實現一個控制系統，使一個人的修改不會對其他人的修改造成負面影響。
樂觀鎖和悲觀鎖控制並發
1.樂觀鎖
樂觀的認為其他用戶企圖訪問和更改你正在訪問的對象的概率很低，即使有，大不了從來一次，對在做一次的開銷不是很大的情況下，如果開銷很大則必須使用悲觀鎖.樂觀鎖的實現需要在程序中控制，可以通過加一個數據版本號來控制比如兩個事物都讀取了同一條記錄要進行更新
Sql代碼
select * from person
select * from person
update person set name='xiaoming',version=version+1 where id='1'
and version=0;
這個更新語句會執行失敗，因為找不到版本好為0的數據，第一個事物已經更新了
pdate person set name='xiaoming',version=version+1 where id='1'
and version=0;
如果實物的隔離級別設置為讀已提交，使用樂觀鎖並能解決可重復度，系統要允許不可重復讀取。
悲觀鎖
很悲觀的認為其他用戶訪問和更改你正在訪問或修改的對象的概率和高，悲觀鎖的實現是通過加鎖來實現的，當要更改數據前就加鎖，別的事物不能操作，sql語句如下
Sql代碼
select * from person for update
update person set name='ff' where id='1'
直到上面事物提交，才能釋放鎖，其他事物才能操作。悲觀鎖的並發性會降低。因此大多數情況下，使用樂觀鎖來實現並發修改。
Ⅸ 悲觀鎖的實現方法
上面這兩種鎖機制是我們在應用層較為常用的，加鎖一般通過以下方法實現：
Criteria.setLockMode
Query.setLockMode
Session.lock
注意，只有在查詢開始之前（也就是 Hiberate 生成 SQL 之前）設定加鎖，才會
真正通過資料庫的鎖機制進行加鎖處理，否則，數據已經通過不包含 for update
子句的 Select SQL 載入進來，所謂資料庫加鎖也就無從談起。
Ⅹ Sql server08資料庫執行什麼操作的時候會加S鎖，IX鎖和SIX鎖
一. 為什麼要引入鎖
多個用戶同時對資料庫的並發操作時會帶來以下數據不一致的問題:
丟失更新
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，則直到事務結束才釋放滾動鎖。
用於保護更新的排它鎖將直到事務結束才釋放。
如果一個連接試圖獲取一個鎖，而該鎖與另一個連接所控制的鎖沖突，則試圖獲取鎖的連接將一直阻塞到：
將沖突鎖釋放而且連接獲取了所請求的鎖。
連接的超時間隔已到期。默認情況下沒有超時間隔，但是一些應用程序設置超時間隔以防止無限期等待
五 SQL Server 中鎖的自定義
1 處理死鎖和設置死鎖優先順序
死鎖就是多個用戶申請不同封鎖,由於申請者均擁有一部分封鎖權而又等待其他用戶擁有的部分封鎖而引起的無休止的等待
可以使用SET DEADLOCK_PRIORITY控制在發生死鎖情況時會話的反應方式。如果兩個進程都鎖定數據，並且直到其它進程釋放自己的鎖時，每個進程才能釋放自己的鎖，即發生死鎖情況。
2 處理超時和設置鎖超時持續時間。
@@LOCK_TIMEOUT 返回當前會話的當前鎖超時設置，單位為毫秒
SET LOCK_TIMEOUT 設置允許應用程序設置語句等待阻塞資源的最長時間。當語句等待的時間大於 LOCK_TIMEOUT 設置時，系統將自動取消阻塞的語句，並給應用程序返回"已超過了鎖請求超時時段"的 1222 號錯誤信息
示例
下例將鎖超時期限設置為 1,800 毫秒。
SET LOCK_TIMEOUT 1800
3) 設置事務隔離級別。
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
同時執行，系統會檢測出死鎖，並中止進程
補充一點:
Sql Server2000支持的表級鎖定提示
HOLDLOCK 持有共享鎖，直到整個事務完成，應該在被鎖對象不需要時立即釋放，等於SERIALIZABLE事務隔離級別
NOLOCK 語句執行時不發出共享鎖，允許臟讀 ，等於 READ UNCOMMITTED事務隔離級別
PAGLOCK 在使用一個表鎖的地方用多個頁鎖
READPAST 讓sql server跳過任何鎖定行，執行事務，適用於READ UNCOMMITTED事務隔離級別只跳過RID鎖，不跳過頁，區域和表鎖
ROWLOCK 強制使用行鎖
TABLOCKX 強制使用獨占表級鎖，這個鎖在事務期間阻止任何其他事務使用這個表
UPLOCK 強制在讀表時使用更新而不用共享鎖
應用程序鎖:
應用程序鎖就是客戶端代碼生成的鎖，而不是sql server本身生成的鎖
處理應用程序鎖的兩個過程
sp_getapplock 鎖定應用程序資源
sp_releaseapplock 為應用程序資源解鎖
注意: 鎖定資料庫的一個表的區別
SELECT * FROM table WITH (HOLDLOCK) 其他事務可以讀取表，但不能更新刪除
SELECT * FROM table WITH (TABLOCKX) 其他事務不能讀取表,更新和刪除