資料庫的事務實現

A. 資料庫事務原子性，一致性是怎樣實現的

原子性：一個事務內的所有sql操作是一個整體。都執行成功才算整個事務成功。如果某個失敗，則必須要會退到事務執行之前的狀態，執行成功的SQL需要被撤銷。
innodb通過undo log和redo log來實現。
事務中，每當執行一條SQL語句對數據產生了影響，就會記錄下來與之相反的操作到undo log(撤銷日誌）中，例如，更新會記錄之前的狀態，刪除會形成insert，添加會形成delete，一旦事務被回滾，則執行undo log中記錄的操作，來完成恢復到之前的狀態。這里是個 邏輯恢復哦！同時，每當執行一條事務中的SQL，會將操作記錄到redo log中，此時事務一旦被提交，就將該redolog中的操作，持久化到磁碟上，數據就持久的記錄下來了（ACID的D）。
PS：還有，undolog才是原子性的關鍵。提供redolog，應該主要目的是提升磁碟的IO開銷吧，如果直接寫入磁碟，IO開銷，會很大。如果先將操作記錄到redolog中，可以順序的記錄，批量的記錄，再一起同步到磁碟上，速度會比直接寫磁碟快些。 mysql在生成redolog時，會使用 innodb log buffer，先緩沖到內存中，再同步到redolog上，速度會更快。
另外關於，一致性，應該是個整體概念，保證所有的mysql對象（數據，索引，約束，日誌，用戶）在事務執行前後都具有完整的特性，應該是mysql所有的功能都為此服務吧！

B. 什麼是資料庫事務

資料庫事務（簡稱：事務）是資料庫管理系統執行過程中的一個邏輯單位，由一個有限的資料庫操作序列構成。
一個資料庫事務通常包含了一個序列的對資料庫的讀/寫操作。它的存在包含有以下兩個目的：
為資料庫操作序列提供了一個從失敗中恢復到正常狀態的方法，同時提供了資料庫即使在異常狀態下仍能保持一致性的方法。
當多個應用程序在並發訪問資料庫時，可以在這些應用程序之間提供一個隔離方法，以防止彼此的操作互相干擾。
當事務被提交給了DBMS（資料庫管理系統），則DBMS（資料庫管理系統）需要確保該事務中的所有操作都成功完成且其結果被永久保存在資料庫中，如果事務中有的操作沒有成功完成，則事務中的所有操作都需要被回滾，回到事務執行前的狀態;同時，該事務對資料庫或者其他事務的執行無影響，所有的事務都好像在獨立的運行。
但在現實情況下，失敗的風險很高。在一個資料庫事務的執行過程中，有可能會遇上事務操作失敗、資料庫系統/操作系統失敗，甚至是存儲介質失敗等情況。這便需要DBMS對一個執行失敗的事務執行恢復操作，將其資料庫狀態恢復到一致狀態（數據的一致性得到保證的狀態）。為了實現將資料庫狀態恢復到一致狀態的功能，DBMS通常需要維護事務日誌以追蹤事務中所有影響資料庫數據的操作。

C. 什麼是資料庫事務

資料庫事務，是指作為單個邏輯工作單元執行的一系列操作，要麼完全地執行，要麼完全地不執行。 事務處理可以確保除非事務性單元內的所有操作都成功完成，否則不會永久更新面向數據的資源。通過將一組相關操作組合為一個要麼全部成功要麼全部失敗的單元，可以簡化錯誤恢復並使應用程序更加可靠。

一個邏輯工作單元要成為事務，必須滿足所謂的ACID(原子性、一致性、隔離性和持久性)屬性。事務是資料庫運行中的邏輯工作單位，由DBMS中的事務管理子系統負責事務的處理。

企業級的資料庫管理系統(DBMS)都有責任提供一種保證事務的物理完整性的機制。就常用的SQL Server2000系統而言，它具備鎖定設備隔離事務、記錄設備保證事務持久性等機制。因此，我們不必關心資料庫事務的物理完整性，而應該關注在什麼情況下使用資料庫事務、事務對性能的影響，如何使用事務等等。

拓展資料：

事務有三種模型:

1、隱式事務是指每一條數據操作語句都自動地成為一個事務，事務的開始是隱式的，事務的結束有明確的標記。

2、顯式事務是指有顯式的開始和結束標記的事務，每個事務都有顯式的開始和結束標記。

3、自動事務是系統自動默認的，開始和結束不用標記。

D. access資料庫能進行事務操作嗎

ACCESS資料庫不支持事務操作，但是我們可以通過ado類庫實現對access資料庫的事務操作。

下面舉例示範ADO類庫實現對ACCESS資料庫的事務操作供參考。注意下列VBA代碼需要先引用ADO類庫

假設有一個團隊表teams和團員表members，每個團隊編號下面都有自己的團員名單，我們每向團員表添加一位團員時，團隊表相應團號的人數就要增加一人，這樣就需要進行兩個操作，一是團員表追加一條記錄，二是團隊表對應團隊的人數更新為增加一人，這兩個操作必須要麼全部成功，要不就全部失敗，不得存在中間狀態，否則記錄就不正確了。如何實現？代碼如下：

PrivateSubCommand0_Click()
OnErrorGoToErr_Command0_Click

DimcnAsADODB.Connection
Setcn=CurrentProject.Connection
cn.BeginTrans'開始執行事務
'向團員表添加一位團員
cn.Execute"insertintomembers(gid,m_name)values("&團隊號碼&",'"&團員名稱&"');"
'相應id團隊的人數增加1人
cn.Execute"updateteamssetpax=IIf(IsNull(pax),0,pax)+1wheregid="&團隊號碼
cn.CommitTrans'結束事務,確保上述兩個操作不會出現一個成功而另一個失敗的狀況
MsgBox"團員添加成功"

Exit_Command0_Click:
ExitSub
Err_Command0_Click:
MsgBoxErr.Description
ResumeExit_Command0_Click

EndSub

E. 資料庫詳解之事務

究竟什麼是資料庫的事務，為什麼資料庫需要支持事務，為了實現資料庫事務各種資料庫的是如何設計的。還是只談理解，歡迎大家來討論。

1. 資料庫事務是什麼

事務的定義，已經有太多文章寫過，我就不重復了。我理解的事務就是用來保證數據操作符合業務邏輯要求而實現的一系列功能。換句話說，如果資料庫不支持事務，上面業務系統的程序員就需要自己寫代碼保證相關數據處理邏輯的正確性。而資料庫事務就是把一系列保證資料庫處理邏輯正確性的通用功能在資料庫內實現，並且盡量提高效率。

舉個例子，資料庫最開始普及就是在金融業，銀行的存取款場景就是一個最典型的OLTP資料庫場景，而事務就是設計用來保證類似場景的業務邏輯正確性的。


**原子性**，如果你要給家人轉賬，必須在你的賬戶里扣掉100塊，在家人賬戶里加上100塊，這兩筆操作需要一起完成，業務邏輯才是正確的。但是程序在做修改的時，肯定會有先後順序，試想一下程序扣了你的錢，這個時候程序崩潰了，家人賬戶的錢沒有加上。那這100塊是不是消失了？你是不是要發瘋？那麼，就把這兩筆操作放進一個事務里，通過原子性保證，這兩筆操作要麼都成功，要麼都失敗。這樣才能保證業務邏輯的正確性。

**一致性**，有很多文章講過一致性，但是很多人會把一致性跟原子性混在一起說。事務的一致性指的是指每一個事務必須保證執行之後所有庫內的規則依舊成立。比如內外鍵，constraint，觸發器等。舉例來說，你在儲蓄卡里有100元，理財賬戶里有100元，基金賬戶有100元，那麼你在資產總和里會看到300元，這個300元必須是其他三個賬戶余額加在一起得到的。你在給家人轉帳100元是從儲蓄卡里轉出去了100元，那麼在資料庫上可以通過創建觸發器的方式，當儲蓄卡余額賬戶減100元的同時，把資產總和也同步減去100，不然的話，就會出現邏輯上的錯誤，因為你已經轉走了100塊儲蓄卡余額，實際資產總和應該是200，如果還是300，資料庫狀態就不一致了。所以實現事務的時候，必須要保證相關聯的觸發器以及其他所有的內部規則都執行成功，事務才能算執行成功。如果在減去資產總時出錯，那麼這筆轉帳交易也不能成功。因為這樣資料庫就會進入不一致的狀態。

那麼這里跟原子性的區別到底在哪裡呢？原子性是指個多個用戶指令之間必須作為一個整體完成或失敗，而一致性更多是資料庫內的相關數據規則必須同時完成或失敗。

**持久性**，最容易理解的一個，事務只要提交了，那麼對資料庫的修改就會保存下來不會丟了。簡單來說，只要提交了，資料庫就算崩潰了，重啟之後你剛存的100塊依然在你的賬戶里。

**隔離性**，每個事務相對於其他的事務是有一定獨立性的，不能互相影響。因為資料庫需要支持並發的操作來提高效率。在並發操作時，一定要通過操作之間的隔離來保證業務邏輯的正確性。比如，你轉帳100塊給家人，一系列操作的最後一步可能是輸入驗證碼，這個時候轉帳還沒有完成，但是在資料庫里你的賬戶對應的記錄中已經減去100塊，家人賬戶也加了100塊，就等著驗證碼輸入以後，事務提交，完成操作。那麼，這個時候，家人通過手機銀行能夠查到這100塊么？你的答案可能是不能，因為這樣才符合業務邏輯，因為你的轉帳操作還沒有提交，事務還沒有完成。那麼資料庫就應該保證這兩個並發操作之間具有一定的隔離性。

那麼到底應該隔離到什麼程度呢？隔離性又分為4個等級：由低到高依次為Read uncommitted(讀未提交)、Read committed（讀提交）、Repeatable read（可重復讀取）、Serializable（序列化），這四個級別可以逐個解決臟讀、不可重復讀、幻象讀這幾類問題。這些東西是什麼意思？請有興趣的小夥伴自行網路，很多文章都寫的很清楚。

那麼怎麼理解不同的隔離等級呢，首先要理解並發操作，並發操作就是指有不同的用戶同時對一個數據進行讀、寫操作，那麼在這個過程中，每個用戶應該看到什麼數據才能保證業務邏輯的正確性呢？ 如果是前面存取款的場景，我必須看到的是已經存進來的錢，也就是必須是已經提交的事務。而12306刷火車票呢，你可以看到有10張余票，但是在下單的時候告訴你票賣完了，因為同時有10個用戶把票買掉了，你需要重新刷余票，這個也是可以接受的，也就是說我可以讀到一些虛假的余票，這樣在業務上也沒有什麼問題。那麼在設計這兩個不同系統時，就可以選擇不同的事務隔離級別來實現不同的並發效果。不同的隔離等級就是要在系統的並發性和數據邏輯的嚴謹性之間做出的平衡。

2. 資料庫如何實現事務

資料庫實現事務會有多種不同的方式，但基本的原理類似，比如都需要對事務進行統一的編號處理，都需要記錄事務的狀態（是成功了還是失敗了），都需要在數據存儲的層面對事務進行支持，以明確哪些數據是被哪些事務、插入、修改和刪除的。同時還會記錄事務日誌等，對事務進行系統化的管理以實現數據的原子性，一致性和持久性。

要實現事務的隔離性，最基礎的就是通過加鎖機制把並發操作適當的串列化來保證數據操作的正確邏輯。但是為了要保證系統具有良好的並發性能，必須要在實現事務隔離性時需要找到合理的平衡點。大部分資料庫（包括Oracle，MySQL，Postgres在內）在做並發控制的時候都會採用MVCC（多版本並發控制）的機制來保證系統具有較高的並發性，不同資料庫實現MVCC的具體方案也不盡相同，但其基本原理類似。

3. MVCC實現原理

所謂MVCC，就是資料庫中的同一查詢根據相關事務執行的先後順序以及隔離級別的不同，可能會存在不同版本的結果，通過這樣的手段來保證大部分查詢操作不會被修改操作阻塞並保證數據邏輯的正確性。也就是資料庫通過保存多個版本的數據（ 歷史 數據）來提高系統的並發查詢能力。簡單來說就是用存儲空間來交換並發能力。下面以Postgres為例介紹一下MVCC的一種實現方式幫助大家理解這個重要的資料庫概念。通過下面的圖來解釋Posrgres里最基本的數據可見性是如何實現多版本控制的。


首先，Postgres里的每一個事務都有編號，這里可以簡單理解為時間順序編號，編號越大的事務發生越晚。然後，資料庫里的每一行記錄都會保存創建這條記錄的事務號（Cre），也會在記錄刪除時保存刪除這條記錄的事務號（Exp），換句話說，只要Exp這里一列里記錄了事務編號，就說明這條記錄被刪除了。那麼一個事務應該能看見那些記錄呢？Postgres里每一個事務都會保存一個當前系統的事務快照（Snapshot），這個快照里會保存事務創建時當前系統的最高（最晚）事務編號，以及目前還在進行中的事務編號。那麼如上圖所示的一個事務的快照里最高事務編號為100，目前正在進行的事務有25，50和75。那麼對應左邊數據記錄，這6行數據的可見性就如同標注的一般：

第一行，Cre 30，沒有刪除，在100這個時間點，應該能看到。

第二行，Cre 50，沒有刪除，但是50這個事務還沒有提交，正在進行中，所以看不見。

第三行，Cre 110，沒有刪除，但是100這個時間點110事務還沒有發生，所以看不見。

第四行，Cre 30，Exp 80，在80的時候數據被刪掉了，所以看不見。

第五行，Cre 30，Exp 75，在30的時候被創建，75時候被刪掉了，但是75這個事務在100的時候還沒有提交，所以這條記錄在100的時候還沒有刪掉，所以看得見。

第六行，Cre30，Exp 110，在30的時被創建，110時候被刪掉，但是在100時候，110還沒有發生，所以看得見。

綜上，就是這個事務對這六條記錄的可見性，也就是一個數據版本。那麼大家可以看一下如果另一個事務的快照里存的是最高事務編號為110，正在進行的事務為50，那麼它能看到的數據應該是哪幾行呢？同時大家也看到，Postgres里刪除一行數據其實就是在這一行的Exp這個列記錄一個刪除事務的編號，相當於做了一個刪除標記，而數據沒有真正被刪除，因此Postgres資料庫需要定期做數據清理操作（Vacuum）。Pstgres的在現實場景里會比這里介紹的要復雜，因為我們這里假定所有的事務最終都是正確提交了，如果存在某些事務沒有提交的情況，那麼可見性就會更加復雜，這里不再展開了。

資料庫事務是基本的資料庫概念，之前已經有很多很好文章做過介紹，這里希望能把自己的理解用比較通俗的描述分享給大家，歡迎來討論交流。

F. 資料庫事務原子性，一致性是怎樣實現的

這個問題的有趣之處，不在於問題本身（「原子性、一致性的實現機制是什麼」），而在於回答者的分歧反映出來的另外一個問題：原子性和一致性之間的關系是什麼？

我特別關注了@我練功發自真心
的答案，他正確地指出了，為了保證事務操作的原子性，必須實現基於日誌的REDO/UNDO機制。但這個答案仍然是不完整的，因為原子性並不能夠完全保證一致性。

按照我個人的理解，在事務處理的ACID屬性中，一致性是最基本的屬性，其它的三個屬性都為了保證一致性而存在的。

首先回顧一下一致性的定義。所謂一致性，指的是數據處於一種有意義的狀態，這種狀態是語義上的而不是語法上的。最常見的例子是轉帳。例如從帳戶A轉一筆錢到帳戶B上，如果帳戶A上的錢減少了，而帳戶B上的錢卻沒有增加，那麼我們認為此時數據處於不一致的狀態。

在
資料庫實現的場景中，一致性可以分為資料庫外部的一致性和資料庫內部的一致性。前者由外部應用的編碼來保證，即某個應用在執行轉帳的資料庫操作時，必須在
同一個事務內部調用對帳戶A和帳戶B的操作。如果在這個層次出現錯誤，這不是資料庫本身能夠解決的，也不屬於我們需要討論的范圍。後者由資料庫來保證，即
在同一個事務內部的一組操作必須全部執行成功（或者全部失敗）。這就是事務處理的原子性。

為了實現原子性，需要通過日誌：將所有對
數據的更新操作都寫入日誌，如果一個事務中的一部分操作已經成功，但以後的操作，由於斷電/系統崩潰/其它的軟硬體錯誤而無法繼續，則通過回溯日誌，將已
經執行成功的操作撤銷，從而達到「全部操作失敗」的目的。最常見的場景是，資料庫系統崩潰後重啟，此時資料庫處於不一致的狀態，必須先執行一個crash
recovery的過程：讀取日誌進行REDO（重演將所有已經執行成功但尚未寫入到磁碟的操作，保證持久性），再對所有到崩潰時尚未成功提交的事務進行
UNDO（撤銷所有執行了一部分但尚未提交的操作，保證原子性）。crash
recovery結束後，資料庫恢復到一致性狀態，可以繼續被使用。

日誌的管理和重演是資料庫實現中最復雜的部分之一。如果涉及到並行處理和分布式系統（日誌的復制和重演是資料庫高可用性的基礎），會比上述場景還要復雜得多。

但是，原子性並不能完全保證一致性。在多個事務並行進行的情況下，即使保證了每一個事務的原子性，仍然可能導致數據不一致的結果。例如，事務1需要將100元轉入帳號A：先讀取帳號A的值，然後在這個值上加上100。但是，在這兩個操作之間，另一個事務2修改了帳號A的值，為它增加了100元。那麼最後的結果應該是A增加了200元。但事實上，
事務1最終完成後，帳號A只增加了100元，因為事務2的修改結果被事務1覆蓋掉了。

為了保證並發情況下的一致性，引入了隔離性，即保證每一個事務能夠看到的數據總是一致的，就好象其它並發事務並不存在一樣。用術語來說，就是多個事務並發執行後的狀態，和它們串列執行後的狀態是等價的。怎樣實現隔離性，已經有很多人回答過了，原則上無非是兩種類型的鎖：

一
種是悲觀鎖，即當前事務將所有涉及操作的對象加鎖，操作完成後釋放給其它對象使用。為了盡可能提高性能，發明了各種粒度（資料庫級/表級/行級……）/各
種性質（共享鎖/排他鎖/共享意向鎖/排他意向鎖/共享排他意向鎖……）的鎖。為了解決死鎖問題，又發明了兩階段鎖協議/死鎖檢測等一系列的技術。

一種是樂觀鎖，即不同的事務可以同時看到同一對象（一般是數據行）的不同歷史版本。如果有兩個事務同時修改了同一數據行，那麼在較晚的事務提交時進行沖突
檢測。實現也有兩種，一種是通過日誌UNDO的方式來獲取數據行的歷史版本，一種是簡單地在內存中保存同一數據行的多個歷史版本，通過時間戳來區分。

鎖也是資料庫實現中最復雜的部分之一。同樣，如果涉及到分布式系統（分布式鎖和兩階段提交是分布式事務的基礎），會比上述場景還要復雜得多。

@
我練功發自真心
提到，其他回答者說的其實是操作系統對atomic的理解，即並發控制。我不能完全同意這一點。資料庫有自己的並發控制和鎖問題，雖然在原理上和操作系統
中的概念非常類似，但是並不是同一個層次上的東西。資料庫中的鎖，在粒度/類型/實現方式上和操作系統中的鎖都完全不同。操作系統中的鎖，在資料庫實現中
稱為latch（一般譯為閂）。其他回答者回答的其實是「在並行事務處理的情況下怎樣保證數據的一致性」。

最後回到原來的問題（「原子性、一致性的實現機制是什麼」）。我手頭有本Database
System
Concepts（4ed，有點老了），在第15章的開頭簡明地介紹了ACID的概念及其關系。如果你想從概念上了解其實現，把這本書的相關章節讀完應該能大概明白。如果你想從實踐上了解其實現，可以找innodb這樣的開源引擎的源代碼來讀。不過，即使是一個非常粗糙的開源實現（不考慮太復雜的並行處理，不考慮分布式系統，不考慮針對操作系統和硬體的優化之類），要基本搞明白恐怕也不是一兩年的事。

G. 資料庫事務正確執行的四個基本要素包括

ACID，指資料庫事務正確執行的四個基本要素的縮寫。包含：原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability）。一個支持事務（Transaction）的資料庫，必需要具有這四種特性，否則在事務過程（Transaction processing）當中無法保證數據的正確性，交易過程極可能達不到交易方的要求。
原子性
整個事務中的所有操作，要麼全部完成，要麼全部不完成，不可能停滯在中間某個環節。事務在執行過程中發生錯誤，會被回滾（Rollback）到事務開始前的狀態，就像這個事務從來沒有執行過一樣。
一致性
一個事務可以封裝狀態改變（除非它是一個只讀的）。事務必須始終保持系統處於一致的狀態，不管在任何給定的時間並發事務有多少。
也就是說：如果事務是並發多個，系統也必須如同串列事務一樣操作。其主要特徵是保護性和不變性(Preserving an Invariant)，以轉賬案例為例，假設有五個賬戶，每個賬戶余額是100元，那麼五個賬戶總額是500元，如果在這個5個賬戶之間同時發生多個轉賬，無論並發多少個，比如在A與B賬戶之間轉賬5元，在C與D賬戶之間轉賬10元，在B與E之間轉賬15元，五個賬戶總額也應該還是500元，這就是保護性和不變性
隔離性
隔離狀態執行事務，使它們好像是系統在給定時間內執行的唯一操作。如果有兩個事務，運行在相同的時間內，執行相同的功能，事務的隔離性將確保每一事務在系統中認為只有該事務在使用系統。這種屬性有時稱為串列化，為了防止事務操作間的混淆，必須串列化或序列化請求，使得在同一時間僅有一個請求用於同一數據。
持久性
在事務完成以後，該事務對資料庫所作的更改便持久的保存在資料庫之中，並不會被回滾。
由於一項操作通常會包含許多子操作，而這些子操作可能會因為硬體的損壞或其他因素產生問題，要正確實現ACID並不容易。ACID建議資料庫將所有需要更新以及修改的資料一次操作完畢，但實際上並不可行。
目前主要有兩種方式實現ACID：第一種是Write ahead logging，也就是日誌式的方式(現代資料庫均基於這種方式)。第二種是Shadow paging。

H. 資料庫中的事務是什麼

資料庫事務（簡稱：事務）是資料庫管理系統執行過程中的一個邏輯單位，由一個有限的資料庫操作序列構成。
一個資料庫事務通常包含了一個序列的對資料庫的讀/寫操作。它的存在包含有以下兩個目的：
為資料庫操作序列提供了一個從失敗中恢復到正常狀態的方法，同時提供了資料庫即使在異常狀態下仍能保持一致性的方法。
當多個應用程序在並發訪問資料庫時，可以在這些應用程序之間提供一個隔離方法，以防止彼此的操作互相干擾。
當事務被提交給了DBMS（資料庫管理系統），則DBMS（資料庫管理系統）需要確保該事務中的所有操作都成功完成且其結果被永久保存在資料庫中，如果事務中有的操作沒有成功完成，則事務中的所有操作都需要被回滾，回到事務執行前的狀態;同時，該事務對資料庫或者其他事務的執行無影響，所有的事務都好像在獨立的運行。
但在現實情況下，失敗的風險很高。在一個資料庫事務的執行過程中，有可能會遇上事務操作失敗、資料庫系統/操作系統失敗，甚至是存儲介質失敗等情況。這便需要DBMS對一個執行失敗的事務執行恢復操作，將其資料庫狀態恢復到一致狀態（數據的一致性得到保證的狀態）。為了實現將資料庫狀態恢復到一致狀態的功能，DBMS通常需要維護事務日誌以追蹤事務中所有影響資料庫數據的操作。

I. 資料庫中的事務是什麼

事物的定義：
資料庫事務(Database Transaction) ，是指作為單個邏輯工作單元執行的一系列操作，要麼完整地執行，要麼完全地不執行。 事務處理可以確保除非事務性單元內的所有操作都成功完成，否則不會永久更新面向數據的資源。通過將一組相關操作組合為一個要麼全部成功要麼全部失敗的單元，可以簡化錯誤恢復並使應用程序更加可靠。一個邏輯工作單元要成為事務，必須滿足所謂的ACID（原子性、一致性、隔離性和持久性）屬性。
============
簡單說事務就是一組操作的集合，而且這組操作必須全部執行成功否者回滾到所有操作前的狀態。

舉個例子什麼時候用到事務：
例如，在將資金從一個帳戶轉移到另一個帳戶的銀行應用中，一個帳戶將一定的金額貸記到一個資料庫表中，同時另一個帳戶將相同的金額借記到另一個資料庫表中。由於計算機可能會因停電、網路中斷等而出現故障，因此有可能更新了一個表中的行，但沒有更新另一個表中的行。如果資料庫支持事務，則可以將資料庫操作組成一個事務，以防止因這些事件而使資料庫出現不一致。如果事務中的某個點發生故障，則所有更新都可以回滾到事務開始之前的狀態。如果沒有發生故障，則通過以完成狀態提交事務來完成更新。

J. 資料庫的事務 作用是

資料庫事務(Database Transaction) ，是指作為單個邏輯工作單元執行的一系列操作，要麼完全地執行，要麼完全地不執行。原子性（Atomic）（Atomicity) 事務必須是原子工作單元；對於其數據修改，要麼全都執行，要麼全都不執行。通常，與某個事務關聯的操作具有共同的目標，並且是相互依賴的。如果系統只執行這些操作的一個子集，則可能會破壞事務的總體目標。原子性消除了系統處理操作子集的可能性。一致性（Consistent）(Consistency) 事務在完成時，必須使所有的數據都保持一致狀態。在相關資料庫中，所有規則都必須應用於事務的修改，以保持所有數據的完整性。事務結束時，所有的內部數據結構（如 B 樹索引或雙向鏈表）都必須是正確的。某些維護一致性的責任由應用程序開發人員承擔，他們必須確保應用程序已強制所有已知的完整性約束。如，當開發用於轉帳的應用程序時，應避免在轉帳過程中任意移動小數點。隔離性（Insulation）(Isolation) 由並發事務所作的修改必須與任何其它並發事務所作的修改隔離。事務查看數據時數據所處的狀態，要麼是另一並發事務修改它之前的狀態，要麼是另一事務修改它之後的狀態，事務不會查看中間狀態的數據。這稱為隔離性，因為它能夠重新裝載起始數據，並且重播一系列事務，以使數據結束時的狀態與原始事務執行的狀態相同。當事務可序列化時將獲得最高的隔離級別。在此級別上，從一組可並行執行的事務獲得的結果與通過連續運行每個事務所獲得的結果相同。由於高度隔離會限制可並行執行的事務數，所以一些應用程序降低隔離級別以換取更大的吞吐量。持久性（Duration）(Durability） 事務完成之後，它對於系統的影響是永久性的。該修改即使出現致命的系統故障也將一直保持。