當前位置:首頁 » 操作系統 » 資料庫隔離性

資料庫隔離性

發布時間: 2022-04-22 04:13:23

Ⅰ mysql資料庫的事務隔離級別有哪些

事務隔離級別的方法:
1.全局修改,修改mysql.ini配置文件,在最後加上
1 #可選參數有:READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE.
2 [mysqld]
3 transaction-isolation = REPEATABLE-READ

這里全局默認是REPEATABLE-READ,其實MySQL本來默認也是這個級別
2.對當前session修改,在登錄mysql客戶端後,執行命令:
set session transaction isolation level read uncommitted;

要記住mysql有一個autocommit參數,默認是on,他的作用是每一條單獨的查詢都是一個事務,並且自動開始,自動提交(執行完以後就自動結束了,如果你要適用select for update,而不手動調用 start transaction,這個for update的行鎖機制等於沒用,因為行鎖在自動提交後就釋放了),所以事務隔離級別和鎖機制即使你不顯式調用start transaction,這種機制在單獨的一條查詢語句中也是適用的,分析鎖的運作的時候一定要注意這一點

Ⅱ 資料庫事務隔離性

事務隔離性(Insulation)(Isolation) 由並發事務所作的修改必須與任何其它並發事務所作的修改隔離。事務查看數據時數據所處的狀態,要麼是另一並發事務修改它之前的狀態,要麼是另一事務修改它之後的狀態,事務不會查看中間狀態的數據。這稱為隔離性,因為它能夠重新裝載起始數據,並且重播一系列事務,以使數據結束時的狀態與原始事務執行的狀態相同。當事務可序列化時將獲得最高的隔離級別。在此級別上,從一組可並行執行的事務獲得的結果與通過連續運行每個事務所獲得的結果相同。由於高度隔離會限制可並行執行的事務數,所以一些應用程序降低隔離級別以換取更大的吞吐量。持久性(Duration)(Durability) 事務完成之後,它對於系統的影響是永久性的。該修改即使出現致命的系統故障也將一直保持。

Ⅲ 資料庫操作的時候,什麼情況下需要用到事務

當資料庫需要處理操作量大、復雜度高的數據的時候需要用到事務。用事務是為了保證資料庫的完整性,保證成批的 SQL 語句要麼全部執行,要麼全部不執行。

一個資料庫事務通常包含了一個序列的對資料庫的讀/寫操作。它的存在包含有以下兩個目的:

1、為資料庫操作序列提供了一個從失敗中恢復到正常狀態的方法,同時提供了資料庫即使在異常狀態下仍能保持一致性的方法。

2、當多個應用程序在並發訪問資料庫時,可以在這些應用程序之間提供一個隔離方法,以防止彼此的操作互相干擾。

當事務被提交給了資料庫管理系統,則資料庫管理系統需要確保該事務中的所有操作都成功完成且其結果被永久保存在資料庫中,如果事務中有的操作沒有成功完成,則事務中的所有操作都需要被回滾,回到事務執行前的狀態;同時,該事務對資料庫或者其他事務的執行無影響,所有的事務都好像在獨立的運行。

(3)資料庫隔離性擴展閱讀:

資料庫事務ACID性質:

1、原子性(Atomicity):事務作為一個整體被執行,包含在其中的對資料庫的操作要麼全部被執行,要麼都不執行。

2、一致性(Consistency):事務應確保資料庫的狀態從一個一致狀態轉變為另一個一致狀態,一致狀態的含義是資料庫中的數據應滿足完整性約束。

3、隔離性(Isolation):多個事務並發執行時,一個事務的執行不應影響其他事務的執行。

4、持久性(Durability):已被提交的事務對資料庫的修改應該永久保存在資料庫中。

參考資料來源:

網路-資料庫事務

網路-資料庫

Ⅳ 關系資料庫事務的特性是什麼

關系資料庫事務(DatabaseTransaction)是指一個可以包含多個步驟來完成所需要的任務的工作單元。通過事務將一系列不可分割的資料庫操作作為一個整體來執行,從而保證了資料庫的完整性和有效性。其包含了一組資料庫操作命令的一個操作序列,事務中所有命令作為一個整體向系統提交或撤銷操作請求(要麼完全執行,要麼完全不執行,即資料庫命令系列要麼都成功,要麼都不成功)。

2.1.1事務特性資料庫事務必須具備ACID特性,一個邏輯工作單元要成為事務,必須滿足ACID屬性。

ACID是指Atomicity(原子性)、Consistency(一致性)、Isolation(隔離性)和Durability(持久性)。事務由資料庫管理系統(DBMS)中的事務管理子系統負責處理。

1.原子性原子性指的是一個事務(Transaction)中的所有操作,要麼全部完成,要麼全部不完成,不會結束在中間某個環節。事務在執行過程中發生錯誤,會被回滾(Rollback)到事務開始前的狀態,就像這個事務從來沒有執行過一樣。

2.一致性一致性指的是在一個事務執行之前和執行之後資料庫都必須處於一致性狀態。如果事務成功完成,那麼系統中所有變化將正確地應用,系統處於有效狀態。如果在事務中出現錯誤,那麼系統中的所有變化將自動地回滾,系統返回到原始狀態。

3.隔離性隔離性指的是在並發環境中,當不同的事務同時操縱相同的數據時,每個事務都有各自的完整數據空間。由並發事務所做的修改必須與任何其他並發事務所做的修改隔離。事務查看數據更新時,數據所處的狀態要麼是另一事務修改它之前的狀態,要麼是另一事務修改它之後的狀態,事務不會查看到中間狀態的數據。

4.持久性持久性指的是只要事務成功結束,它對資料庫所做的更新就必須永久地保存下來。即使發生系統崩潰,重新啟動資料庫系統後,資料庫還能恢復到事務成功結束時的狀態。

Ⅳ 資料庫事務的特性是什麼

原子性(Atomicity)

一致性(Consistency)

隔離性(Isolation)

持久性(Durability)

⑴ 原子性(Atomicity)
原子性是指事務包含的所有操作要麼全部成功,要麼全部失敗回滾,因此事務的操作如果成功就必須要完全應用到資料庫,如果操作失敗則不能對資料庫有任何影響。

⑵ 一致性(Consistency)
一致性是指事務必須使資料庫從一個一致性狀態變換到另一個一致性狀態,也就是說一個事務執行之前和執行之後都必須處於一致性狀態。

拿轉賬來說,假設用戶A和用戶B兩者的錢加起來一共是5000,那麼不管A和B之間如何轉賬,轉幾次賬,事務結束後兩個用戶的錢相加起來應該還得是5000,這就是事務的一致性。

⑶ 隔離性(Isolation)
隔離性是當多個用戶並發訪問資料庫時,比如操作同一張表時,資料庫為每一個用戶開啟的事務,不能被其他事務的操作所干擾,多個並發事務之間要相互隔離。

即要達到這么一種效果:對於任意兩個並發的事務T1和T2,在事務T1看來,T2要麼在T1開始之前就已經結束,要麼在T1結束之後才開始,這樣每個事務都感覺不到有其他事務在並發地執行。

關於事務的隔離性資料庫提供了多種隔離級別。

⑷ 持久性(Durability)
持久性是指一個事務一旦被提交了,那麼對資料庫中的數據的改變就是永久性的,即便是在資料庫系統遇到故障的情況下也不會丟失提交事務的操作。

Ⅵ oracle 資料庫隔離級別學習

oracle
事務隔離級別
事務不同引發的狀況:
臟讀(Dirty
reads)
一個事務讀取另一個事務尚未提交的修改時,產生臟讀
很多資料庫允許臟讀以避免排它鎖的競爭。
不可重復讀(Nonrepeatable
reads)
同一查詢在同一事務中多次進行,由於其他提交事務所做的修改或刪除,每次返回不同的結果集,此時發生非重復讀。
幻讀(Phantom
reads)
同一查詢在同一事務中多次進行,由於其他提交事務所做的插入操作,每次返回不同的結果集,此時發生幻像讀。
資料庫操作的隔離級別
未提交讀(read
uncommitted)
提交讀(read
committed)
重復讀(repeatable
read)
序列化(serializable)
oracle默認隔離級別read
committed
(statement
level
serialization)
每一個語句,在語句開始時,會獲取一個此刻的數據快照。
一個事務有多條語句,如果語句之間存在其它完成的事務,這可能引起不可持續讀和幻讀。
新建一個測試表books:
name,code,price三個欄位
添加兩條測試數據
使用pl/sql和java程序模擬並發
不允許臟讀測試:
程序段首先查詢code是qqq的書的價格
復制代碼
代碼如下:
//獲取連接
省略
pstat
=
conn.prepareStatement("select
price
from
books
where
code='qqq'");
rs
=
pstat.executeQuery();
while(rs.next()){

System.out.println("price:"+rs.getDouble(1));
}
close();
輸出結果:price:15.0
然後pl/sql執行更新
復制代碼
代碼如下:
update
books
set
price=18
where
code='qqq'
!pl/sql設置成手動更新,不自動更新
在執行上面java查詢代碼
輸出仍是price:15.0,說明讀不到pl/sql中未提交的執行結果,即不允許臟讀
pl/sql
執行
commit;
在執行java查詢:
輸出結果:price:18.0
會有不可重復讀何幻讀的現象發生就不用測試了吧,
這兩種現象都是針對提交後事物的讀引起的,read
commited隔離級別是允許對提交後
的事物進行讀的。
隔離級別:重復讀(repeatable
read)
這個不允許臟讀,不可重復讀,但是會有幻讀現象。
這個oracle不支持,不好測試。
理解的話就是如果一條查詢語句查詢的內容有其它事物正在更新的時候,這
查詢處於等待狀態,直到先前事物提交更新後,才會執行本條查詢。也就是
查詢的時候也會有鎖,需要等待並發的事物釋放鎖。然後自己獲取到鎖,執行
自己事物。這樣查詢也加鎖,並發性更低
select
...
for
update
就是這樣可以避免不可重復讀的發生
隔離級別:serializable
這個就更嚴格了,事物執行是一個一個的。一個事務中的語句共享同一個數據快照(在事務開始時存在的數據)。
是事物級別的,臟讀,不可重復讀,幻讀根本就沒有機會發生。
前面像read
committed都是語句級別的,以語句為單元。
比如
read
committed一個事物A有a(select),b(select),c(update)三條語句
當A事物執行a,b的時候,若有B事物執行更新操作,是有可能的
因為a,b是不加鎖的
例子:
復制代碼
代碼如下:
//獲取連接和關閉連接代碼
省略
//不自動提交
conn.setAutoCommit(false);
/**
*
a
查詢
*/
pstat
=
conn.prepareStatement("select
price
from
books
where
code='qqq'");
rs
=
pstat.executeQuery();
while(rs.next()){

//輸出
price:25.0

System.out.println("price:"+rs.getDouble(1));
}
close();
/**
*
暫停一會,用pl/sql執行B事務
*
update
books
set
price=15
where
code='qqq'
*
commit;
*/
Thread.sleep(10000);
/**
*
如果這里再執行a查詢的話,和第一次查詢結果就不一樣,因為中間有B事務的提交更新
*
修改,這也是不可重復讀
*/
//b
更新
pstat
=
conn.prepareStatement("update
books
set
price=price+10
where
code='qqq'");
pstat.executeUpdate();
close();
//c
查詢
pstat
=
conn.prepareStatement("select
price
from
books
where
code='qqq'");
rs
=
pstat.executeQuery();
while(rs.next()){

//輸出
還是price:25.0
,因為B事務的干預

System.out.println("price:"+rs.getDouble(1));
}
close();
//提交事務
conn.commit();
if(conn
!=
null){

conn.close();
}
上面執行的順序,事務B是在A的執行過程中執行的。
以上通過實例介紹了oracle資料庫隔離級別的相關內容,希望對大家有所幫助。
下面是一些補充:
資料庫中的事務基本作用是將資料庫從一致狀態轉換到另一種一致狀態,那麼事務隔離級別就是定義了一個事務對於另外一個事務做出的修改有多「敏感」。也就是不同的隔離級別定義了事務相互影響的程度,下面分別介紹一下幾種不同的隔離級別。
1.
READ
UNCOMMITTED
其實,oracle不支持這種隔離級別。這種隔離級別允許臟讀(也就是可以讀取到用戶未提交的數據),支持這種隔離級別的資料庫主要是為了支持非阻塞讀,但是oracle默認支持非阻塞讀,所以oracle裡面不支持這種隔離級別。下面舉一個例子:
如上圖所示,假設某一家銀行要統計所有賬號總共有多少金額。事務A負責統計,事務A從第一行開始讀取。假設讀取到100行的時候,事務B從賬號123轉了400元到賬戶987(事務B還未提交),支持臟讀的資料庫當事務A讀取到342023行的時候,就會得到500元,從而多加了400元。
2.
READ
COMMITTED
這種隔離級別指的是,事務只能讀取已經提交的數據,(但是支持可重復讀與幻想讀)是oracle資料庫默認的隔離模式。其實這種隔離級別在別的資料庫裡面可能還是會「退化」得像臟讀一樣。就看前面那個例子,假設在事務A讀取到342023行前,事務B提前鎖定了這一行,並將金額由100改成了500。那麼事務A讀取到這一行的時候,發現已經被其他事務鎖定了,於是進行等待,直到事務B提交。但是當事務B提交之後,事務A還是讀取到了500這一個錯誤信息,這樣就和臟讀一樣的了,而且還讓用戶等待這個錯誤的答案。
3.
REPEATABLE
READ
這種隔離級別不支持臟讀,不支持可重復讀,支持幻想讀。主要是為了得到一致性的答案與防止丟失更新。
a.
得到一致性答案
在oracle裡面這個通過多版本機製得到了實現,但是在其他的資料庫需要通過加鎖機制進行控制,就以上一個例子為例,怎樣才能統計出正確的總金額呢,事務A在讀取每一行的時候,給每一行加上共享讀鎖,這樣當事務B執行從賬號123轉400元到賬戶987的時候。先是操作第一行將賬戶123的金額由500修改成100,但是第一行已經被事務A鎖定,於是等待,這樣事務A能夠讀取到正確的數據。但是如果事務B執行的操作是從賬戶987轉50元到賬戶123的時候,事務B先操作第342023行,發現沒有被鎖定,於是鎖定將金額由100修改成50,然後操作第一行,發現鎖定了於是等待。而事務A讀取到342023行的時候,發現這一行已經被事務B鎖定於是等待,這樣就陷入了死鎖。
b.
丟失更新
在採用共享讀鎖的資料庫中,這種隔離級別可以防止丟失更新,比如事務1先讀取了第A行然後修改了這一行的C列(其他列也修改了只是值還和以前一樣,因為程序員都是整行的更新)。這個時候事務2想也想修改A行的時候會被阻塞,防止事務1的更新被覆蓋。
4.
SEAIALIZABLE
不允許臟讀,重復讀與幻想讀,最高的隔離級別。這種隔離級別標明事務A在操作資料庫的時候好像就只有事務A在操作,沒有其他事務在操作資料庫一樣。
Oracle
中是這樣實現
SERIALIZABLE
事務的:原本通常在語句級得到的讀一致性現在可以擴展到事務級。也就是在事務執行的那一刻,將這個事務將要操作的數據拍了一張照片。
從上面的例子我們可以看出,其他資料庫採用共享讀鎖來解決統計總金額問題是沒有oracle多版本機制靈活的,其一嚴重影響了程序的並發性,讀阻塞了寫。其二可能引起死鎖。

Ⅶ 資料庫一致性模型和隔離級別

資料庫下一步發展的基礎:分布式SQL,分布式SQL是部署在單個數據中心中的多個物理節點或多個數據中心(如果需要)中的單個邏輯資料庫。所有這些都使其能夠提供彈性的氧化皮和防彈的彈性。今天我們就來聊聊資料庫一致性模型和隔離級別。

Ⅷ 怎麼查看資料庫隔離級別

修改方法

有兩種方法可以對配置了 systemd 的程序進行資源隔離:1. 命令行修改:通過執行systemctl set-property命令實現,形式為systemctl set-propertyname parameter=value;修改默認即時生效。2. 手工修改文件:直接編輯程序的 systemd unit file 文件,完成之後需手工執行systemctldaemon-reload更新配置,並重啟服務systemctl restart name.service。

systemd unit file 里支持的資源隔離配置項,如常見的:

  • CPUQuota=value

    該參數表示服務可以獲取的最大 CPU 時間,value 為百分數形式,高於 100% 表示可使用1 核以上的CPU。與 cgroup cpu 控制器cpu.cfs_quota_us配置項對應。

  • MemoryLimit=value

    該參數表示服務可以使用的最大內存量,value 可以使用 K, M, G, T 等後綴表示值的大小。與 cgroupmemory 控制器memory.limit_in_bytes配置項對應。

  • 事務的4種隔離級別

    READ UNCOMMITTED 未提交讀,可以讀取未提交的數據。

    READ COMMITTED 已提交讀,對於鎖定讀(select with for update 或者 for share)、update 和 delete 語句,InnoDB 僅鎖定索引記錄,而不鎖定它們之間的間隙,因此允許在鎖定的記錄旁邊自由插入新記錄。

    Gap locking 僅用於外鍵約束檢查和重復鍵檢查。

    REPEATABLE READ 可重復讀,事務中的一致性讀取讀取的是事務第一次讀取所建立的快照。

    SERIALIZABLE 序列化在了解了 4 種隔離級別的需求後,在採用鎖控制隔離級別的基礎上,我們需要了解加鎖的對象(數據本身&間隙),以及了解整個數據范圍的全集組成。

    數據范圍全集組成

    SQL 語句根據條件判斷不需要掃描的數據范圍(不加鎖);

    SQL 語句根據條件掃描到的可能需要加鎖的數據范圍;

    以單個數據范圍為例,數據范圍全集包含:(數據范圍不一定是連續的值,也可能是間隔的值組成)

Ⅸ 如果不考慮資料庫隔離級別,會帶來哪些問題

隔離級別越高,越能保證數據的完整性和一致性,但是對並發性能的影響也越大。對於多數應用程序,可以優先考慮把資料庫系統的隔離級別設為Read Committed,它能夠避免臟讀取,而且具有較好的並發性能。盡管它會導致不可重復讀、虛讀和第二類丟失更新這些並發問題,在可能出現這類問題的個別場合,可以由應用程序採用悲觀鎖或樂觀鎖來控制。

Ⅹ 資料庫事務的四個隔離級別,mysql在哪一個級別

術式之後皆為邏輯,一切皆為需求和實現。希望此文能從需求、現狀和解決方式的角度幫大家理解隔離級別。


隔離級別的產生

在串型執行的條件下,數據修改的順序是固定的、可預期的結果,但是並發執行的情況下,數據的修改是不可預期的,也不固定,為了實現數據修改在並發執行的情況下得到一個固定、可預期的結果,由此產生了隔離級別。

所以隔離級別的作用是用來平衡資料庫並發訪問與數據一致性的方法。


事務的4種隔離級別

READ UNCOMMITTED 未提交讀,可以讀取未提交的數據。READ COMMITTED 已提交讀,對於鎖定讀(select with for update 或者 for share)、update 和 delete 語句, InnoDB 僅鎖定索引記錄,而不鎖定它們之間的間隙,因此允許在鎖定的記錄旁邊自由插入新記錄。 Gap locking 僅用於外鍵約束檢查和重復鍵檢查。REPEATABLE READ 可重復讀,事務中的一致性讀取讀取的是事務第一次讀取所建立的快照。SERIALIZABLE 序列化

在了解了 4 種隔離級別的需求後,在採用鎖控制隔離級別的基礎上,我們需要了解加鎖的對象(數據本身&間隙),以及了解整個數據范圍的全集組成。


數據范圍全集組成

SQL 語句根據條件判斷不需要掃描的數據范圍(不加鎖);

SQL 語句根據條件掃描到的可能需要加鎖的數據范圍;

以單個數據范圍為例,數據范圍全集包含:(數據范圍不一定是連續的值,也可能是間隔的值組成)

1. 數據已經填充了整個數據范圍:(被完全填充的數據范圍,不存在數據間隙)

  • 整形,對值具有唯一約束條件的數據范圍 1~5 ,

    已有數據1、2、3、4、5,此時數據范圍已被完全填充;

  • 整形,對值具有唯一約束條件的數據范圍 1 和 5 ,

    已有數據1、5,此時數據范圍已被完全填充;

  • 2. 數據填充了部分數據范圍:(未被完全填充的數據范圍,是存在數據間隙)

  • 整形的數據范圍 1~5 ,

    已有數據 1、2、3、4、5,但是因為沒有唯一約束,

    所以數據范圍可以繼續被 1~5 的數據重復填充;

  • 整形,具有唯一約束條件的數據范圍 1~5 ,

    已有數據 2,5,此時數據范圍未被完全填充,還可以填充 1、3、4 ;

  • 3. 數據范圍內沒有任何數據(存在間隙)

    如下:

  • 整形的數據范圍 1~5 ,數據范圍內當前沒有任何數據。

  • 在了解了數據全集的組成後,我們再來看看事務並發時,會帶來的問題。

    無控制的並發所帶來的問題

    並發事務如果不加以控制的話會帶來一些問題,主要包括以下幾種情況。

    1. 范圍內已有數據更改導致的:

  • 更新丟失:當多個事務選擇了同一行,然後基於最初選定的值更新該行時,

    由於每個事物不知道其他事務的存在,最後的更新就會覆蓋其他事務所做的更新;

  • 臟讀: 一個事務正在對一條記錄做修改,這個事務完成並提交前,這條記錄就處於不一致狀態。

    這時,另外一個事務也來讀取同一條記錄,如果不加控制,

    第二個事務讀取了這些「臟」數據,並據此做了進一步的處理,就會產生提交的數據依賴關系。

    這種現象就叫「臟讀」。

  • 2. 范圍內數據量發生了變化導致:

  • 不可重復讀:一個事務在讀取某些數據後的某個時間,再次讀取以前讀過的數據,

    卻發現其讀出的數據已經發生了改變,或者某些記錄已經被刪除了。

    這種現象就叫「不可重復讀」。

  • 幻讀:一個事務按相同的查詢條件重新讀取以前檢索過的數據,

    卻發現其他事務插入了滿足其查詢條件的新數據,這種現象稱為「幻讀」。

    可以簡單的認為滿足條件的數據量變化了。

  • 因為無控制的並發會帶來一系列的問題,這些問題會導致無法滿足我們所需要的結果。因此我們需要控制並發,以實現我們所期望的結果(隔離級別)。

    MySQL 隔離級別的實現

    InnoDB 通過加鎖的策略來支持這些隔離級別。

    行鎖包含:

  • Record Locks

    索引記錄鎖,索引記錄鎖始終鎖定索引記錄,即使表中未定義索引,

    這種情況下,InnoDB 創建一個隱藏的聚簇索引,並使用該索引進行記錄鎖定。

  • Gap Locks

    間隙鎖是索引記錄之間的間隙上的鎖,或者對第一條記錄之前或者最後一條記錄之後的鎖。

    間隙鎖是性能和並發之間權衡的一部分。

    對於無間隙的數據范圍不需要間隙鎖,因為沒有間隙。

  • Next-Key Locks

    索引記錄上的記錄鎖和索引記錄之前的 gap lock 的組合。

    假設索引包含 10、11、13 和 20。

    可能的next-key locks包括以下間隔,其中圓括弧表示不包含間隔端點,方括弧表示包含端點:

  • (負無窮大, 10] (10, 11] (11, 13] (13, 20] (20, 正無窮大) 對於最後一個間隔,next-key將會鎖定索引中最大值的上方,


  • 左右滑動進行查看

    "上確界"偽記錄的值高於索引中任何實際值。

    上確界不是一個真正的索引記錄,因此,實際上,這個 next-key 只鎖定最大索引值之後的間隙。

    基於此,當獲取的數據范圍中,數據已填充了所有的數據范圍,那麼此時是不存在間隙的,也就不需要 gap lock。

    對於數據范圍內存在間隙的,需要根據隔離級別確認是否對間隙加鎖。

    默認的 REPEATABLE READ 隔離級別,為了保證可重復讀,除了對數據本身加鎖以外,還需要對數據間隙加鎖。

    READ COMMITTED 已提交讀,不匹配行的記錄鎖在 MySQL 評估了 where 條件後釋放。

    對於 update 語句,InnoDB 執行 "semi-consistent" 讀取,這樣它會將最新提交的版本返回到 MySQL,

    以便 MySQL 可以確定該行是否與 update 的 where 條件相匹配。

    總結&延展:

    唯一索引存在唯一約束,所以變更後的數據若違反了唯一約束的原則,則會失敗。

    當 where 條件使用二級索引篩選數據時,會對二級索引命中的條目和對應的聚簇索引都加鎖;所以其他事務變更命中加鎖的聚簇索引時,都會等待鎖。

    行鎖的增加是一行一行增加的,所以可能導致並發情況下死鎖的發生。

    例如,

    在 session A 對符合條件的某聚簇索引加鎖時,可能 session B 已持有該聚簇索引的 Record Locks,而 session B 正在等待 session A 已持有的某聚簇索引的 Record Locks。

    session A 和 session B 是通過兩個不相乾的二級索引定位到的聚簇索引。

    session A 通過索引 idA,session B通過索引 idB 。

    當 where 條件獲取的數據無間隙時,無論隔離級別為 rc 或 rr,都不會存在間隙鎖。

    比如通過唯一索引獲取到了已完全填充的數據范圍,此時不需要間隙鎖。

    間隙鎖的目的在於阻止數據插入間隙,所以無論是通過 insert 或 update 變更導致的間隙內數據的存在,都會被阻止。

    rc 隔離級別模式下,查詢和索引掃描將禁用 gap locking,此時 gap locking 僅用於外鍵約束檢查和重復鍵檢查(主要是唯一性檢查)。

    rr 模式下,為了防止幻讀,會加上 Gap Locks。

    事務中,SQL 開始則加鎖,事務結束才釋放鎖。

    就鎖類型而言,應該有優化鎖,鎖升級等,例如rr模式未使用索引查詢的情況下,是否可以直接升級為表鎖。

    就鎖的應用場景而言,在回放場景中,如果確定事務可並發,則可以考慮不加鎖,加快回放速度。

    鎖只是並發控制的一種粒度,只是一個很小的部分:

    從不同場景下是否需要控制並發,(已知無交集且有序的數據的變更,MySQL 的 MTS 相同前置事務的多事務並發回放)

    並發控制的粒度,(鎖是一種邏輯粒度,可能還存在物理層和其他邏輯粒度或方式)

    相同粒度下的優化,(鎖本身存在優化,如IX、IS類型的優化鎖)

    粒度載入的安全&性能(如獲取行鎖前,先獲取頁鎖,頁鎖在執行獲取行鎖操作後即釋放,無論是否獲取成功)等多個層次去思考並發這玩意。

熱點內容
mac訪問windows共享 發布:2024-10-01 23:31:58 瀏覽:637
java培訓要學什麼 發布:2024-10-01 23:15:54 瀏覽:532
c語言編程學習寶典 發布:2024-10-01 22:35:08 瀏覽:341
無法打開腳本文件 發布:2024-10-01 22:14:51 瀏覽:105
javaxml格式字元串格式 發布:2024-10-01 21:54:03 瀏覽:651
為什麼安卓玩游戲都選驍龍 發布:2024-10-01 21:48:07 瀏覽:372
如何避免伺服器暴露ip 發布:2024-10-01 21:38:24 瀏覽:216
pythonrequestjson 發布:2024-10-01 21:37:37 瀏覽:854
珠海java 發布:2024-10-01 21:07:29 瀏覽:820
伺服器剩餘維護是什麼 發布:2024-10-01 21:03:46 瀏覽:543