為什麼無法撤消已送出的事務
一旦事務被送出，我們就不能通過中止它來撤銷它的影響。
我們有一個日誌文件，其中包含撤消已送出事務的所有資訊，那麼為什麼這不可能呢？我們應該能夠對已送出的事務執行相同的操作，就像對已中止的事務執行的操作一樣。
過去中止的事務從未被其他事務“看到”，因此它現在對數據庫中目前的任何數據都沒有影響！
一個已送出的事務（稱為 X）被其他事務（比如 Y 和 Z… 以及可能的許多其他事務）看到，它們的動作（
INSERTs、UPDATEs 或DELETEs）可能取決於 X 實際上已送出的事實並且進一步的交易（A、B、C、D….）可能依賴於 Y 和 Z。有（可能）大量的交易可能會或可能不會產生不同的結果，具體取決於先前的交易 - 這些混雜效應至少是指數級的，可能是階乘的，甚至更糟。
在相對較短的時間後，您將很快需要磁碟上的比特數超過地球上的原子數，以跟踪此級聯的所有潛在結果。在國際象棋遊戲中，前 10 位棋手（兩位棋手）有
**69,353,270,203,366**（69.3 萬億）可能的走法（有待商榷 - 見頁面）——因此，即使只有少數人執行CrUD操作，也只能想像可能的場景數量（此處的 r 小寫，因為您無法回滾讀取 (SELECT) 操作，因為沒有數據更改）！這就是為什麼沒有回滾已送出事務的機制的原因——當然你可以回滾那個事務X——如果它仍然使數據庫處於邏輯一致的狀態——即根據 DDL、外鍵一致、
CHECK約束 &c .但從業務/應用程序的角度來看，它可能不一致 - 庫存數量（只是我能想到的無數變數之一）可能不正確……其他潛在錯誤的數量也很大！考慮任何在應該觸發時可能沒有觸發的觸發器，反之亦然。
這是一個等待發生的銀河規模SNAFU，這也是任何主要 RDBMS 提供商都沒有實現這種功能的原因（謝天謝地）——而且也不太可能實現！當然，不可能的事實不會成為聲稱提供此類功能的公司的障礙 - “蛇油”一詞會浮現在腦海中！