資料庫鎖類型

A. 處理鎖死優先考慮的順序

處理鎖死優先考慮的順序：

先預防和避免，再檢測和恢復。

資料庫經常鎖死的原因：

資料庫是一個多用戶使用的共享資源，當多個用戶並發地存取數據時，在資料庫中就會產生多個事務同時存取同一數據的情況。若對並發操作不加控制就可能會讀取和存儲不正確的數據，破壞資料庫的一致性。加鎖是實現資料庫並發控制的一個非常重要的技術。

在實際應用中經常會遇到的與鎖相關的異常情況，當兩個事務需要一組有沖突的鎖，而不能將事務繼續下去的話，就會出現死鎖，嚴重影響應用的正常執行。

在資料庫中有兩種基本的鎖類型：排它鎖（Exclusive Locks，即X鎖）和共享鎖（Share Locks，即S鎖）。當數據對象被加上排它鎖時，其他的事務不能對它讀取和修改。

加了共享鎖的數據對象可以被其他事務讀取，但不能修改。資料庫利用這兩種基本的鎖類型來對資料庫的事務進行並發控制。

出現原因：

用戶A查詢一條紀錄，然後修改該條紀錄；這時用戶B修改該條紀錄，這時用戶A的事務里鎖的性質由查詢的共享鎖企圖上升到獨占鎖。

而用戶B里的獨占鎖由於A有共享鎖存在所以必須等A釋放掉共享鎖，而A由於B的獨占鎖而無法上升的獨占鎖也就不可能釋放共享鎖，於是出現了死鎖。這種死鎖由於比較隱蔽，但在稍大點的項目中經常發生。

B. 資料庫中,鎖有哪幾種類型,分別表示什麼涵義什麼是兩段領協議

摘要 兩段鎖協議：是指所有的事務必須分兩個階段對數據項加鎖和解鎖。即事務分兩個階段，第一個階段是獲得封鎖。事務可以獲得任何數據項上的任何類型的鎖，但是不能釋放；第二階段是釋放封鎖，事務可以釋放任何數據項上的任何類型的鎖，但不能申請。

C. Oracle資料庫鎖的常用類型有哪些

Oracle資料庫的鎖類型

根據保護的對象不同，Oracle資料庫鎖可以分為以下幾大類：DML鎖（data locks，數據鎖），用於保護數據的完整性；DDL鎖（dictionary locks，字典鎖），用於保護資料庫對象的結構，如表、索引等的結構定義；內部鎖和閂（internal locks and latches），保護資料庫的內部結構。

DML鎖的目的在於保證並發情況下的數據完整性，本文主要討論DML鎖。在Oracle資料庫中，DML鎖主要包括TM鎖和TX鎖，其中TM鎖稱為表級鎖，TX鎖稱為事務鎖或行級鎖。

當Oracle執行DML語句時，系統自動在所要操作的表上申請TM類型的鎖。當TM鎖獲得後，系統再自動申請TX類型的鎖，並將實際鎖定的數據行的鎖標志位進行置位。這樣在事務加鎖前檢查TX鎖相容性時就不用再逐行檢查鎖標志，而只需檢查TM鎖模式的相容性即可，大大提高了系統的效率。TM鎖包括了SS、SX、S、X等多種模式，在資料庫中用0－6來表示。不同的sql操作產生不同類型的TM鎖。如表1所示。

在數據行上只有X鎖（排他鎖）。在 Oracle資料庫中，當一個事務首次發起一個DML語句時就獲得一個TX鎖，該鎖保持到事務被提交或回滾。當兩個或多個會話在表的同一條記錄上執行DML語句時，第一個會話在該條記錄上加鎖，其他的會話處於等待狀態。當第一個會話提交後，TX鎖被釋放，其他會話才可以加鎖。

當Oracle資料庫發生TX鎖等待時，如果不及時處理常常會引起Oracle資料庫掛起，或導致死鎖的發生，產生ORA-60的錯誤。這些現象都會對實際應用產生極大的危害，如長時間未響應，大量事務失敗等。

TX鎖等待的分析

在介紹了有關地Oracle資料庫鎖的種類後，下面討論如何有效地監控和解決鎖等待現象，及在產生死鎖時如何定位死鎖的原因。

監控鎖的相關視圖 數據字典是Oracle資料庫的重要組成部分，用戶可以通過查詢數據字典視圖來獲得資料庫的信息。和鎖相關的數據字典視圖如表2所示。

TX鎖等待的監控和解決在日常工作中，如果發現在執行某條SQL時資料庫長時間沒有響應，很可能是產生了TX鎖等待的現象。為解決這個問題，首先應該找出持鎖的事務，然後再進行相關的處理，如提交事務或強行中斷事務。

死鎖的監控和解決在資料庫中，當兩個或多個會話請求同一個資源時會產生死鎖的現象。死鎖的常見類型是行級鎖死鎖和頁級鎖死鎖，Oracle資料庫中一般使用行級鎖。下面主要討論行級鎖的死鎖現象。

當Oracle檢測到死鎖產生時，中斷並回滾死鎖相關語句的執行，報ORA-00060的錯誤並記錄在資料庫的日誌文件alertSID.log中。同時在user_mp_dest下產生了一個跟蹤文件，詳細描述死鎖的相關信息。

在日常工作中，如果發現在日誌文件中記錄了ora-00060的錯誤信息，則表明產生了死鎖。這時需要找到對應的跟蹤文件，根據跟蹤文件的信息定位產生的原因。

如果查詢結果表明，死鎖是由於bitmap索引引起的，將IND_T_PRODUCT_HIS_STATE索引改為normal索引後，即可解決死鎖的問題。

表1 Oracle的TM鎖類型
鎖模式 鎖描述 解釋 SQL操作
0 none
1 NULL 空 Select
2 SS(Row-S) 行級共享鎖，其他對象只能查詢這些數據行 Select for update、Lock for update、Lock row share

3 SX(Row-X) 行級排它鎖，在提交前不允許做DML操作 Insert、Update、Delete、Lock row share

4 S(Share) 共享鎖 Create index、Lock share
5 SSX(S/Row-X) 共享行級排它鎖 Lock share row exclusive
6 X(Exclusive) 排它鎖 Alter table、Drop able、Drop index、Truncate table 、Lock exclusive

表2 數據字典視圖說明
視圖名 描述 主要欄位說明
v$session 查詢會話的信息和鎖的信息。 sid,serial#：表示會話信息。

program：表示會話的應用程序信息。

row_wait_obj#：表示等待的對象。

和dba_objects中的object_id相對應。

v$session_wait 查詢等待的會話信息。 sid：表示持有鎖的會話信息。

Seconds_in_wait：表示等待持續的時間信息

Event：表示會話等待的事件。

v$lock 列出系統中的所有的鎖。 Sid：表示持有鎖的會話信息。

Type：表示鎖的類型。值包括TM和TX等。

ID1：表示鎖的對象標識。

lmode,request：表示會話等待的鎖模式的信

息。用數字0－6表示，和表1相對應。

dba_locks 對v$lock的格式化視圖。 Session_id：和v$lock中的Sid對應。

Lock_type：和v$lock中的type對應。

Lock_ID1： 和v$lock中的ID1對應。

Mode_held,mode_requested：和v$lock中

的lmode,request相對應。

v$locked_object 只包含DML的鎖信息，包括回滾段和會話信息。 Xisn,xidslot,xidsqn：表示回滾段信息。和

v$transaction相關聯。

Object_id：表示被鎖對象標識。

Session_id：表示持有鎖的會話信息。

Locked_mode：表示會話等待的鎖模式的信

息，和v$lock中的lmode一致。

col owner for a12
col object_name for a16
select b.owner,b.object_name,l.session_id,l.locked_mode
from v$locked_object l, dba_objects b
where b.object_id=l.object_id;

select t2.username,t2.sid,t2.serial#,t2.logon_time
from v$locked_object t1,v$session t2
where t1.session_id=t2.sid order by t2.logon_time;

如果有長期出現的一列，可能是沒有釋放的鎖。我們可以用下面SQL語句殺掉長期沒有釋放非正常的鎖：

alter system kill session 'sid,serial# ';

如果出現了鎖的問題, 某個DML操作可能等待很久沒有反應。

當你採用的是直接連接資料庫的方式，也不要用OS系統命令 $kill process_num 或者 $kill -9 process_num來終止用戶連接，因為一個用戶進程可能產生一個以上的鎖, 殺OS進程並不能徹底清除鎖的問題

Oracle鎖表(死鎖) 2011-05-03 17:46:41| 分類： Java技術 | 標簽： |字型大小大中小 訂閱 .

資料庫與操作系統一樣，是一個多用戶使用的共享資源。 當多個用戶並發地存取數據時，在資料庫中就會發生多個事務同時存取同一數據地情況。 若對並發操作不加控制就可能會讀取和存儲不正確地數據，破壞資料庫地一致性。 加鎖時實現資料庫並發控制地一個非常重要地技術。 在實際應用中經常會遇到地與鎖相關地異常情況，當兩個事務需要一組有沖突的鎖，而不能將事務繼續下去的話，就會出現死鎖，嚴重影響應用的正常執行。

在資料庫中有兩種基本的鎖類型：排它鎖（Exclusive Locks，即X鎖）和共享鎖（即S鎖）。當數據對象被加上排它鎖時，其他的事務不能不能對它讀取和修改。加了共享鎖的數據對象可以被其他事務讀取，但不能修改。資料庫利用這兩種基本的鎖類型來對資料庫的事務進行並發控制。

死鎖的第一種情況：

一個用戶A訪問表A（鎖住了表A），然後又訪問表B； 另一個用戶B訪問表B（鎖住了表B），然後企圖訪問表A；這時用戶A由於用戶B已經鎖住表B，它必須等待用戶B釋放表B才能繼續，同樣用戶B要等用戶A釋放表A才能繼續，這就死鎖產生了。

解決方法：

這種死鎖比較常見，是由於程序的BUG產生的，除了調整程序的邏輯沒有其它的辦法。仔細分析程序的邏輯，對於資料庫的多表操作時，盡量按照同樣的順序進行處理，盡量避免同時鎖定兩個資源，如操作A和B兩張表時，總是按先A後B的順序處理，必須同時鎖定兩個資源時，要保證在任何時刻都應該按照相同的順序來鎖定資源。

死鎖的第二種情況

用戶A查詢一條記錄，然後修改該條記錄；這時用戶B修改該條記錄，這時用戶A的事務里鎖的性質由查詢的共享鎖企圖上升到獨占鎖，而用戶B里的獨占鎖由於A有共享鎖存在必須等A釋放掉共享鎖，而A由於B的獨占鎖而無法上升到獨占鎖也就不可能釋放共享鎖，於是出現了死鎖。這種死鎖比較隱蔽，但在稍大點的項目種經常發生，如在某項目中，頁面上的按鈕點擊後，沒有使按鈕立刻失效，使得用戶會多次快速點擊同一按鈕，這樣同一段代碼對資料庫同一條記錄進行多次操作，很容易就出現這種死鎖的情況。

解決方法：

1、對於按鈕等控制項，點擊後使其立刻失效，不讓用戶重復點擊，避免對同時對同一條記錄操作。

2、使用樂觀鎖進行控制。樂觀鎖大多是基於數據版本（version）記錄機制實現。即為數據增加一個版本標識，在基於資料庫表的版本解決方案中，一般是通過為資料庫增加一個「version」欄位來實現。讀取處數據時，將此版本號一同讀出，之後更新時，對此版本號加一。此時，將提交的數據的版本數據與資料庫表對應記錄的當前版本信息進行比對，如果提交的數據版本號大於資料庫表當前版本號，則予以更新，否則認為是過期數據。樂觀鎖機制避免了長事務中的資料庫加鎖開銷（用戶A和用戶B操作過程中，都沒有對資料庫加鎖），大大提升了大並發量下的系統整體性表現。 Hibernate在其數據訪問引擎中內置了樂觀鎖實現。需要注意的是，由於樂觀鎖機制是我們的系統中實現，來自外部系統的用戶更新操作不受我們系統的控制，因此可能會造成臟數據被更新到資料庫中。

3、使用悲觀鎖進行控制。悲觀鎖大多數情況下依靠資料庫的鎖機制實現，如Oracle的select.......for update語句，以保證操作最大程度的獨占性。但隨之而來的就是資料庫性能的大量開銷，特別是對長事務而言，這樣的開銷往往無法承受。如一個金融系統，當某個操作員讀取用戶的數據，並在讀出的用戶數據的基礎上進行修改時（如更改用戶帳戶余額），如果採用悲觀鎖機制，也就意味整個操作過程中（從操作員讀出數據、開始修改直至提交修改結果的全過程，甚至還包括操作員中途去煮咖啡的時間），資料庫記錄始終處於加鎖狀態，可以想見，如果面對成百上千個並發，這樣的情況將導致災難性的結果。所以，採用悲觀鎖進行控制時一定要考慮清楚。

死鎖的第三種情況

如果在事務種執行了一條不滿足條件的update語句，則執行全表掃描，把行級鎖上升為表級鎖，多個這樣的事務執行之後，就很容易發生死鎖和阻塞。類似的情況還有當表種的數據量非常龐大而索引建的過少或不合適的時候，使得經常發生全表掃描，最終應用系統會越來越慢，最終發生阻塞或死鎖。

解決方法：

SQL語句中不要使用太復雜的關聯多表的查詢；使用「執行計劃」對SQL語句進行 分析，對於有全表掃描的SQL語句，建立相應的索引進行優化。

***查詢死鎖表以及解鎖表***

通過select * from v$locked_object

可以獲得被鎖的對象的object_id及產生鎖的會話sid，通過查詢結果中的object_id，可以查詢到具體被鎖的對象。

鎖有以下幾種模式:
0：none
1：null 空
2：Row-S 行共享(RS / S鎖)：共享表鎖
3：Row-X 行專用(RX / X鎖)：用於行的修改
4：Share 共享鎖(S)：阻止其他DML操作
5：S/Row-X 共享行專用(SRX)：阻止其他事務操作
6：exclusive 專用(X)：獨立訪問使用
數字越大鎖級別越高, 影響的操作越多。

一般的查詢語句如select ... from ... ;是小於2的鎖, 有時會在v$locked_object出現。

select ... from ... for update; 是2的鎖。

當對話使用for update子串打開一個游標時，
所有返回集中的數據行都將處於行級(Row-X)獨占式鎖定，
其他對象只能查詢這些數據行，不能進行update、delete或select...for update操作。

insert / update / delete ... ; 是3的鎖。

沒有commit之前插入同樣的一條記錄會沒有反應,
因為後一個3的鎖會一直等待上一個3的鎖, 我們必須釋放掉上一個才能繼續工作。

創建索引的時候也會產生3,4級別的鎖。

locked_mode為2,3,4不影響DML(insert,delete,update,select)操作,
但DDL(alter,drop等)操作會提示ora-00054錯誤。

有主外鍵約束時 update / delete ... ; 可能會產生4,5的鎖。

DDL語句時是6的鎖。

以DBA角色, 查看當前資料庫里鎖的情況可以用如下SQL語句：

select object_id,session_id,locked_mode from v$locked_object;

select t2.username,t2.sid,t2.serial#,t2.logon_time
from v$locked_object t1,v$session t2
where t1.session_id=t2.sid order by t2.logon_time;

如果有長期出現的一列，可能是沒有釋放的鎖。

我們可以用下面SQL語句殺掉長期沒有釋放非正常的鎖：

D. mysql資料庫的行級鎖有幾種

有兩種模式的行鎖：
1）共享鎖：允許一個事務去讀一行，阻止其他事務獲得相同數據集的排他鎖。
( Select * from table_name where ......lock in share mode)
2）排他鎖：允許獲得排他鎖的事務更新數據，阻止其他事務取得相同數據集的共享讀鎖和 排他寫鎖。(select * from table_name where.....for update)

E. oracle中的鎖有什麼作用都有什麼鎖之間有什麼區別謝謝

資料庫是一個多用戶使用的共享資源。當多個用戶並發地存取數據時，在資料庫中就會產生多個事務同時存取同一數據的情況。若對並發操作不加控制就可能會讀取和存儲不正確的數據，破壞資料庫的一致性。 加鎖是實現資料庫並發控制的一個非常重要的技術。當事務在對某個數據對象進行操作前，先向系統發出請求，對其加鎖。加鎖後事務就對該數據對象有了一定的控制，在該事務釋放鎖之前，其他的事務不能對此數據對象進行更新操作。 在資料庫中有兩種基本的鎖類型：排它鎖（Exclusive Locks，即X鎖）和共享鎖（Share Locks，即S鎖）。當數據對象被加上排它鎖時，其他的事務不能對它讀取和修改。加了共享鎖的數據對象可以被其他事務讀取，但不能修改。資料庫利用這兩種基本的鎖類型來對資料庫的事務進行並發控制。 根據保護的對象不同，Oracle資料庫鎖可以分為以下幾大類： DML鎖（data locks，數據鎖），用於保護數據的完整性； DDL鎖（dictionary locks，字典鎖），用於保護資料庫對象的結構，如表、索引等的結構定義； 內部鎖和閂（internal locks and latches），保護資料庫的內部結構，應用於SGA； 在我們實際應用開發中涉及較多的是DML鎖，其他兩種的話DBA會更加關心點； DML鎖的目的在於保證並發情況下的數據完整性，主要包括TM鎖和TX鎖，其中TM鎖稱為表級鎖，TX鎖稱為事務鎖或行級鎖。 當Oracle執行DML語句時，系統自動在所要操作的表上申請TM類型的鎖。當TM鎖獲得後，系統再自動申請TX類型的鎖，並將實際鎖定的數據行的鎖標志位進行置位。這樣在事務加鎖前檢查TX鎖相容性時就不用再逐行檢查鎖標志，而只需檢查TM鎖模式的相容性即可，大大提高了系統的效率。TM鎖包括了SS、SX、S、X等多種模式，在資料庫中用0－6來表示。不同的SQL操作產生不同類型的TM鎖。如下圖所示： 值 鎖模式 鎖描述 SQL 0 NONE 1 NULL 空 SELECT 2 SS(ROW-S) 行級共享鎖 其他對象只能查詢這些數據行 SELECT FOR UPDATE、LOCK FOR UPDATE、 LOCK ROW SHARE 3 SX(ROW-X) 行級排它鎖 在提交前不允許做DML操作 INSERT、UPDATE、DELETE、 LOCK ROW SHARE 4 S(SHARE) 共享鎖 CREATE INDEX、LOCK SHARE 5 SSX(S/ROW-X) 共享行級排它鎖 LOCK SHARE ROW EXCLUSIVE 6 X(eXclusive) 排它鎖 ALTER TABLE、DROP TABLE、DROP INDEX、 TRUNCATE TABLE、LOCK EXCLUSIVE 在數據行上只有X鎖（排他鎖）。在 Oracle資料庫中，當一個事務首次發起一個DML語句時就獲得一個TX鎖，該鎖保持到事務被提交或回滾。當兩個或多個會話在表的同一條記錄上執行 DML語句時，第一個會話在該條記錄上加鎖，其他的會話處於等待狀態。當第一個會話提交後，TX鎖被釋放，其他會話才可以加鎖。 在大概了解oracle的鎖機制之後，我們來解決幾個基本的問題： 1.UPDATE/DELETE操作會將RS鎖定，直至操作被COMMIT或者ROLLBACK； 若操作未COMMIT之前其他session對同樣的RS做變更操作，則操作會被hold，直至前session的UPDATE/DELETE操作被COMMIT； 2.session內外SELECT的RS范圍 前提：INSERT、UPDATE操作未COMMIT之前進行SELECT； 若在同一session內，SELECT出來的RS會包括之前INSERT、UPDATE影響的記錄； 若不在同一session內，SELECT出來的RS不會包括未被COMMIT的記錄； 3.SELECT.... FOR UPDATE [OF cols] [NOWAIT/WAIT] [SKIP LOCKED] OF cols：只鎖定指定欄位所在表的RS，而沒有指定的表則不會鎖定，只會在多表聯合查詢時出現； NOWAIT：語句不會hold，而是直接返回錯誤ORA-0005

F. 資料庫中什麼是S鎖什麼是X鎖它們區別是什麼

基本的封鎖類型有兩種:排它鎖(X鎖)和共享鎖(S鎖).所謂X鎖,是事務T對數據A加上X鎖時,只允許事務T讀取和修改數據A,...所謂S鎖,是事務T對數據A加上S鎖時,其他事務只能再對數據A加S鎖,而不能加X鎖,直到T釋放A上的S鎖
若事務T對數據對象A加了S鎖,則T就可以對A進行讀取,但不能進行更新(S鎖因此又稱為讀鎖),在T釋放A上的S鎖以前,其他事務可以再對A加S鎖,但不能加X鎖,從而可以讀取A,但不能更新A.

G. Oracle資料庫鎖有哪些種類

鎖的種類：

共享鎖： 這個鎖是數據在被viewed的時候放置的。

排他鎖： 這種鎖在Insert, Update, Delete命令執行的時候放置的，每一條記錄同一時間只能有一個排他鎖。

H. ORACLE里幾種鎖模式

ORACLE鎖具體分為以下幾類：

1.按用戶與系統劃分，可以分為自動鎖與顯示鎖

自動鎖：當進行一項資料庫操作時，預設情況下，系統自動為此資料庫操作獲得所有有必要的

顯示鎖：某些情況下，需要用戶顯示的鎖定資料庫操作要用到的數據，才能使資料庫操作執行得更好，顯示鎖是用戶為資料庫對象設定的。

2.按鎖級別劃分，可分為共享鎖與排它鎖

共享鎖：共享鎖使一個事務對特定資料庫資源進行共享訪問——另一事務也可對此資源進行訪問或獲得相同共享鎖。共享鎖為事務提供高並發性，但如拙劣的事務設計+共享鎖容易造成死鎖或數據更新丟失。

排它鎖：事務設置排它鎖後，該事務單獨獲得此資源，另一事務不能在此事務提交之前獲得相同對象的共享鎖或排它鎖。

3.按操作劃分，可分為DML鎖、DDL鎖

+DML鎖又可以分為，行鎖、表鎖、死鎖

-行鎖：當事務執行資料庫插入、更新、刪除操作時，該事務自動獲得操作 表中操作行的排它鎖。

-表級鎖：當事務獲得行鎖後，此事務也將自動獲得該行的表鎖(共享鎖),以防止其它事務進行DDL語句影響記錄行的更新。事務也可以在進行 過程中獲得共享鎖或排它鎖，只有當事務顯示使用LOCK TABLE語 句顯示的定義一個排它鎖時，事務才會獲得表上的排它鎖,也可使用
LOCK TABLE顯示的定義一個表級的共享鎖(LOCK TABLE具體用法請參 考相關文檔)。
-死鎖：當兩個事務需要一組有沖突的鎖，而不能將事務繼續下去的話，就 出現死鎖。
如事務1在表A行記錄#3中有一排它鎖，並等待事務2在表A中記錄#4 中排它鎖的釋放，而事務2在表A記錄行#4中有一排它鎖，並等待事務 1在表A中記錄#3中排它鎖的釋放，事務1與事務2彼此等待，因此就造 成了死鎖。死鎖一般是因拙劣的事務設計而產生。
死鎖只能使用SQL下:alter system kill session 'sid,serial#'；
或者使用相關操作系統kill進程的命令，如UNIX下kill -9 sid,或者 使用其它工具殺掉死鎖進程。

+DDL鎖又可以分為：排它DDL鎖、共享DDL鎖、分析鎖
-排它DDL鎖：創建、修改、刪除一個資料庫對象的DDL語句獲得操作對象的 排它鎖。
如使用alter table語句時，為了維護數據的完成性、一致性、
合法性，該事務獲得一排它DDL鎖。

-共享DDL鎖：需在資料庫對象之間建立相互依賴關系的DDL語句通常需共享
獲得DDL鎖。
如創建一個包，該包中的過程與函數引用了不同的資料庫表，
當編譯此包時，該事務就獲得了引用表的共享DDL鎖。

-分析鎖：ORACLE使用共享池存儲分析與優化過的SQL語句及PL/SQL程序，使
運行相同語句的應用速度更快。一個在共享池中緩存的對象獲得
它所引用資料庫對象的分析鎖。分析鎖是一種獨特的DDL鎖類型，
ORACLE使用它追蹤共享池對象及它所引用資料庫對象之間的依賴 關系。當一個事務修改或刪除了共享池持有分析鎖的資料庫對象
時，ORACLE使共享池中的對象作廢，下次在引用這條SQL/PLSQL語 句時，ORACLE重新分析編譯此語句。

4.內部閂鎖

內部閂鎖：這是ORACLE中的一種特殊鎖，用於順序訪問內部系統結構。
當事務需向緩沖區寫入信息時，為了使用此塊內存區域， ORACLE首先必須取得這塊內存區域的閂鎖，才能向此塊內存寫入
信息。

I. 資料庫鎖表是什麼意思

1、資料庫鎖表的意思：因為在資料庫里，同一個數據可能有多個人來讀取或更改，為了防止我更改的時候別人也同時更改，這是一般要鎖住表不讓別人改。

2、舉個簡單例子：在更新資料庫記錄的過程中，我是不希望別人也來更新我的這些記錄的，像庫存，做出庫的時候，原數量100，我出了20，我就需要把數量更新到80；

在更新的過程中，別人又做了30的出庫，如果在我更新的時候，別人先把庫存更新到70，然後我又更新80，那數量就錯誤了。所以我更新的時候，我就需要鎖定這條記錄。這是數據行鎖，排他鎖。

(9)資料庫鎖類型擴展閱讀：

資料庫鎖表的必要條件：

1）互斥條件：指進程對所分配到的資源進行排它性使用，即在一段時間內某資源只由一個進程佔用。如果此時還有其它進程請求資源，則請求者只能等待，直至佔有資源的進程用畢釋放。

2）請求和保持條件：指進程已經保持至少一個資源，但又提出了新的資源請求，而該資源已被其它進程佔有，此時請求進程阻塞，但又對自己已獲得的其它資源保持不放。

3）不剝奪條件：指進程已獲得的資源，在未使用完之前，不能被剝奪，只能在使用完時由自己釋放。

4）環路等待條件：指在發生死鎖時，必然存在一個進程——資源的環形鏈，即進程集合{P0，P1，P2，···，Pn}中的P0正在等待一個P1佔用的資源；P1正在等待P2佔用的資源，……，Pn正在等待已被P0佔用的資源。

J. sql資料庫里鎖是什麼

ix是意向鎖。

意向鎖與其說是鎖，倒不如說更像一個指示器。在SQL Server中，資源是有層次的，一個表中可以包含N個頁，而一個頁中可以包含N個行。當我們在某一個行中加了鎖時。可以理解成包含這個行的頁，和表的一部分已經被鎖定。當另一個查詢需要鎖定頁或是表時，再一行行去看這個頁和表中所包含的數據是否被鎖定就有點太痛苦了。因此SQL Server鎖定一個粒度比較低的資源時，會在其父資源上加上意向鎖，告訴其他查詢這個資源的某一部分已經上鎖。比如，當我們更新一個表中的某一行時，其所在的頁和表都會獲得意向排他鎖，如圖所示。