問題匯總：

• 什么是事務
• 事務的特征-ACID
• 事務的原理
• 事務隔離級別
• 并發事務帶來的問題 - 數據庫隔離現象
• 不可重復讀與幻讀的區別
• 事務隔離機制解決方法
• 什么是MVCC
• MVCC是如何工作的
• MVCC需要注意的問題
• 事務日志

---

什么是事務

• 一系列有序的數據庫操作：
  • 要么全部成功
  • 要么全部回退到操作前的狀態
  • 中間狀態對其他連接不可見
• 事務的基本操作：

-- 開啟一個事務 start transaction; -- 或者使用(非標準sql) begin; insert into t values (1, 1, 1); -- 事務結束，插入成功 commit;begin; insert into t values (2, 1, 1); insert into t values (3, 1, 1); insert into t values (4, 1, 1); -- 事務結束，沒有插入數據 rollback;begin;insert into t values (1, 1, 1); savepoint a1; insert into t values (2, 1, 1); -- 回滾到指定的保存點 rollback to a1; commit;

事務的特征-ACID

• 原子性 包含在事務中的操作要么全部被執行，要么都不執行
  中途數據庫或應用發生異常，未提交的事務都應該被回滾
• 一致性 事務前后數據的完整性必須保持一致。
  事務開始和結束時，外部數據一致
  在整個事務過程中，操作是連續的
• 隔離性數據庫事務在提交完成前，中間的任何數據變化對其他的事務都是不可見的。
  事務的隔離性通過鎖、MVCC來實現。
• 持久性一個事務一旦被提交，它對數據庫中的數據改變就是永久性的。

事務的原理

• 利用InnoDB的自動提交(autocommit)特性完成。
• 普通的MySQL執行語句后，當前的數據提交操作均可被其他客戶端可見。
• 而事務是暫時關閉“自動提交”機制，需要commit提交持久化數據操作。

事務隔離級別

讀未提交 (read uncommitd)：別人改數據的事務尚未提交，我在我的事務中也能讀到。讀已提交 （read commited 簡稱：RC）：別人改數據的事務已經提交，我在我的事務中才能讀到。 可重復讀 (repeatable read 簡稱：RR)：別人改數據的事務已經提交，我在我的事務中也讀不到。除非數據是被本事務自己所修改。innoDB默認隔離級別：可重復讀串行化 (serializable)：我的事務尚未提交，別人就別想改數據。

這四種隔離級別，從上到下，并行能力依次降低，安全性一次提高。

InnoDB自動提交特性設置

SET autocommit = 0|1; 0表示關閉自動提交，1表示開啟自動提交。

注意：

1、數據定義語言（DDL）語句不能被回滾，比如創建或取消數據庫的語句，和創建、取消或更改表或存儲的子程序的語句
2、事務不能被嵌套

并發事務帶來的問題-數據庫隔離現象

• 更新丟失（Lost Update）
• 臟讀（Dirty Reads）：讀取到了未提交的數據
• 不可重復讀（Non-Repeatable Reads）一個事務讀取同一條記錄2次，得到的結果不一致
• 幻讀 （Phantom Reads）一個事務讀取2次，得到的記錄條數不一致 解決：MVCC，間隙鎖。

不可重復讀與幻讀的區別

• 不可重復讀的重點是修改：在同一事務中，同樣的條件，第一次讀的數據和第二次讀的數據不一樣。（因為中間有其他事務提交了修改）
• 幻讀的重點在于新增或者刪除：在同一事務中，同樣的條件，第一次和第二次讀出來的記錄數不一樣。（因為中間有其他事務提交了插入/刪除）

事務隔離機制解決方法：

• 加鎖：在讀取數據前，對其加鎖，阻止其他事務對數據進行修改。
• MVCC： 數據多版本并發控制（MultiVersion Concurrency Control）。不用加任何鎖， 通過一定機制生成一個數據請求時間點的一致性數據快照（Snapshot)。只適用于RR、RC隔離級別。

什么是MVCC

MVCC(Multiversion concurrency control) 就是 同一份數據臨時保留多版本的一種方式，進而實現并發控制

MVCC是如何工作的

InnoDB的MVCC是通過在每行記錄后面保存兩個隱藏的列來實現。
事務開始時刻的系統版本號會作為事務的版本號，用來查詢到每行記錄的==版本號進行比較==。

MVCC需要注意的問題

• 在讀寫并發的過程中如何實現多版本？
• 在讀寫并發之后，如何實現舊版本的刪除（畢竟很多時候只需要一份最新版的數據就夠了）？ 在MySQL中建表時，每個表都會有三列隱藏記錄，其中和MVCC有關系的有兩列：
• 數據行的版本號 （DB_TRX_ID）
• 刪除版本號 (DB_ROLL_PT)

事務日志

事務的隔離性是通過==鎖==實現。
事務的原子性、一致性和持久性則是通過==事務日志==實現。
說到事務日志，不得不說的就是redo和undo。redo log 重做日志 - 在innoDB的存儲引擎中，事務日志通過重做(redo)日志和innoDB存儲引擎的日志緩沖(InnoDB Log Buffer)實現。 - 事務開啟時，事務中的操作，都會先寫入存儲引擎的日志緩沖中，在事務提交之前，這些緩沖的日志都需要提前刷新到磁盤redo log上持久化，這就是DBA們口中常說的“日志先行”(Write-Ahead Logging)。 - 當事務提交之后，在Buffer Pool中映射的數據文件才會慢慢刷新到磁盤。

在系統啟動的時候，就已經為redo log分配了一塊連續的存儲空間,以順序追加的方式記錄Redo Log,通過順序IO來改善性能。

undo log 回滾日志 - undo log記錄了數據在每個操作前的狀態，如果事務執行過程中需要回滾，就可以根據undo log進行回滾操作。
redo log其實保障的是事務的持久性和一致性。
undo log則保障了事務的原子性。

以上只是問題點的匯總，有什么不夠準確的地方，請大家指正。后續可以進一步展開來講。

總結

以上是生活随笔為你收集整理的事务未提交 别人能读取到吗_Mysql 事务-面试笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。