從事務理論的角度來看，可以把事務分為以下幾種類型
扁平事務(Flat Transactions)
帶有保存點的扁平事務(Flat Transactions with Savepoints)
鏈事務(Chained Transactions)
嵌套事務(Nested Transactions)
分布式事務(Distributed Transactions)
扁平事務 是事務類型中最簡單的一種，但是在實際生產環境中，這可能是使用最頻繁的事務，在扁平事務中，所有操作都處於同一層次，其由BEGIN WORK開始，由COMMIT WORK或ROLLBACK WORK結束，其間的操作是源自的，要么都執行，要么都回滾，因此扁平事務是應用程序稱為原子操作的的基本組成模塊
下面顯示了扁平事務的三種不同結果
給出的扁平事務的三種情況，同時也給出了一個典型的事務處理應用中，每個結果大概占用的百分比。再次提醒，扁平事務雖然簡單，但是在實際環境中使用最為頻繁，也正因為其簡單，使用頻繁，故每個數據庫系統都實現了對扁平事務的支持
扁平事務的主要限制是不能提交或者回滾事務的某一部分，或分幾個步驟提交。下面給出一個扁平事務不足以支持的例子。例如用戶在旅行網站上進行自己的旅行度假計划，用戶設想從杭州到意大利的佛羅倫薩，這兩個城市沒有直達的班機，需要用戶預訂並轉呈航班，需要或者搭火車等待。用戶預訂旅行度假的事務為
BEGIN WORK：
S1：預訂杭州到上海的高鐵
S2：上海浦東國際機場坐飛機，預訂到米蘭的航班
S3：在米蘭轉火車前往佛羅倫薩，預訂去佛羅倫薩的火車
但是當用戶執行到S3時，發現由於飛機到達米蘭的時間太晚，已經沒有當天的火車，這時用戶希望在米蘭當地住一晚，第二天出發去佛羅倫薩。這時如果事務為扁平事務，需要回滾之前S1 S2 S3的三個操作，這個代價明顯很大，因為當再次進行該事務是，S1 S2的執行計划是不變的，也就是說，如果支持有計划的回滾操作，那么不需要終止整個事務，因此就出現了帶有保存點的扁平事務
帶有保存點的扁平事務 除了支持扁平事務支持的操作外，允許在事務執行過程中回滾同一事務中較早的一個狀態。這是因為某些事務可能在執行過程中出現的錯誤並不會導致所有的操作都無效，放棄整個事務不合乎要求，開銷太大，保存點用來通知事務系統應該記住事務當前的狀態，以便當之后發生錯誤時，事務能回到保存點當時的狀態
對於扁平的事務來說，隱式的設置了一個保存點。然而整個事務中，只有這一個保存點，因此，回滾只能會滾到事務開始時的狀態，保存點用SAVE WORK函數來建立，通知系統記錄當前的處理狀態。當出現問題時，保存點能用作內部的重啟動點，根據應用邏輯，決定是回到最近一個保存點還是其他更早的保存點。圖顯示了事務中使用的保存點
顯示了如何在事務中使用保存點，灰色背景部分表示由ROLLBACK WORK而導致部分回滾，實際並沒有執行操作，當用BEGIN WORK開啟一個事務時，隱式地包含了一個保存點，當事務通過ROLLBACK WORK：2發出部分回滾命令時，事務會滾到保存點2，接着依次執行，並再次執行到ROLLBACK WORK：7，知道最后COMMIT WORK操作，表示事務結束，除灰色陰影部分的操作外，其余操作都已經執行，並且提交
另一個需要注意的是，保存點在事務內部是遞增的，從圖中可以看出，有人可能會想，返回保存點2以后，下一個保存點可以為3，因為之前的工作已經終止，然而新的保存點編號為5，這意味着ROLLBACKU 不影響保存點的計數，並且單調遞增編號能保持事務執行的整個歷史過程，包括在執行過程中想法的改變
此外，當事務通過ROLLBACK WORK：2命令發出部分回滾命令時，要記住事務並沒有完全被回滾，只是回滾到保存點2而已，這代表當前事務是活躍的，如果想要回滾事務，還需要執行ROLLBACKUP WORK
鏈事務 可視為保存點模式的一種變種，帶有保存點的扁平事務，當發生系統崩潰是，所有的的保存點都將消失，因為其保存點是易失的，這意味着當進行恢復時，事務需要從開始處重新執行，而不能從最近的一個保存點繼續執行
鏈事務的思想是：在提交一個事務時，釋放不需要的數據對象，將必要的處理上下文隱式地傳給下一個要開始的事務，提交事務操作和開始下一個事務操作 將合並為一個原子操作，這意味着下一個事務將看到上一個事務的結果，就好像一個事務中進行的一樣，如圖顯示了鏈事務的工作方式
鏈事務與帶有保存點的扁平事務不同的是，帶有保存點的扁平事務能回滾到任意正確的保存點，而鏈事務中的回滾僅限當前事務，即只能恢復到最近的一個保存點，對於鎖的處理，兩者也不相同，鎖事務在執行COMMIT后即釋放了當前所持有的鎖，而帶有保存點的扁平事務不影響迄今為止所持有的鎖
嵌套事務 是一個層次結構框架，由一個頂層事務(top-level transaction)控制着各個層次的事務，頂層事務之下嵌套的事務被稱為子事務，其控制每一個局部的變換，結構如下
下面給出MOSS對嵌套事務的定義
1 嵌套事務是由若干事務組成的一棵樹，子樹既可以是嵌套事務也可以是扁平事務
2 處在葉節點的事務是扁平事務，但是每個事務從根到葉節點的距離可以說是不同的
3 位於根節點的事務稱為頂層事務，其他稱為自事務。事務的前驅稱(predecessor)為父事務(parent)，事務的下一層稱為兒子事務(child)
4 子事務既可以提交也可以回滾。但是它的提交操作並不馬上生效。除非其父事務已經提交。因此可以推論出，任何子事務都在頂層事務提交后才真正的提交
5 樹中的任意事務回滾會引起它的所有子事務一同回滾，故子事務僅保留ACI特性而不具有D特性
在Moss的理論中，實際的工作是交由葉子節點完成，即只有葉子節點的事務才能才能訪問數據庫、發送信息、獲取其他類型的資源。而高層的事務僅負責邏輯控制。決定合適調用相關的子事務。即使一個系統不支持嵌套事務，用戶也可以通過保存點技術來模擬嵌套事務，如圖
如圖可以發現，在恢復時采用保存點技術比嵌套查詢有更大的靈活性。例如在完成Tk3這事務時，可以會滾到保存點S2的狀態。而在嵌套查詢的層次結構中，這是不被允許的
但是用保存點技術來模擬嵌套事務在鎖的持有方面還是與嵌套查詢有些區別。當通過保存點技術來模擬嵌套事務時，用戶無法選擇哪些鎖需要被子事務集成，哪些需要被父事務保留，這就是說，無論有多少個保存點，所有被鎖住的隊形都可以被得到和訪問。而在嵌套查詢中，不同的子事務在數據庫對象上持有的鎖是不同觀點。例如一個父事務P1 其持有對象X和Y的排他鎖，現在要開始調用子事務P11 ,那么父事務P1 可以不傳遞鎖，也可以傳遞所有的鎖，也可以只傳遞一個排他鎖，如果子事務P11 中還持有對象Z的排他鎖，那么通過反向繼承(counter-inherited)父事務P1 將持有3個對象X Y Z的排他鎖。如果這時再次調用一個子事務P12 ，那么它可以傳遞哪里已經持有的鎖
然而，如果系統支持嵌套事務中並行地執行的各個子事務，在這種情況下，采用保存點的扁平事務來模擬嵌套事務就不切實際了。這從另一個方面反映出，想要實現事務間的並行性，需要真正支持的嵌套事務
分布式事務 通常是一個分布式環境下運行的扁平事務，因此需要根據數據所在位置訪問網絡中的不同節點
假如一個用戶在ATM機上進行銀行的轉賬操作，例如持卡人從招商銀行存儲卡轉賬10 000 元到工商銀行的存儲卡。這種情況下，可以將ATM機視為節點A，招商銀行的后台數據庫視為節點B，工商銀行的后台數據庫視為C，這個轉賬的操作可分解為以下的步驟
節點A發出轉賬命令
節點B執行存儲卡中的余額減去10 000
節點C執行存儲卡終端的余額增加10 000
節點A通知用戶操作完成或者節點A通知用戶操作失敗
這里需要使用到分布式事務，因為節點A不能通過一台數據庫就完成任務，其需要訪問網絡中兩個節點的數據庫，而在每個節點的數據庫執行的實務操作有都是扁平的，對於分布式事務，其同樣需要滿足ACID特性，要么都發生，要么都失敗。對於上述例子，如果2 3 步中任何一個操作失敗，都會導致整個分布式事務回滾，若非這樣，結果非常可怕
對於InnoDB存儲引擎來說，其支持扁平事務，帶保存點的事務，鏈事務，分布式事務。對於嵌套事務，其原生不支持。因此對有並發事務需求的用戶來說,MySQL數據庫或InnoDB存儲引擎就顯得無能為力，然而用戶仍可以通過帶保存點的事務來模擬串行的嵌套事務