一、MySQL 日志：undo log、redo log、binlog
undo log（回滾日志）：是 Innodb 存儲引擎層生成的日志，實現了事務中的原子性，主要用于事務回滾和 MVCC（隔離性）。
redo log（重做日志）：是 Innodb 存儲引擎層生成的日志，實現了事務中的持久性，主要用于掉電等故障恢復；
binlog （歸檔日志）：是 Server 層生成的日志，主要用于數據備份和主從復制；
MVCC（多版本并發控制）詳解
MVCC是數據庫領域用于解決高并發場景下讀寫沖突的核心技術。其核心思想是：為數據的每一次修改生成一個 “版本”，讀操作只訪問符合條件的歷史版本，從而實現 “讀不加鎖、寫不阻塞讀”，大幅提升數據庫并發性能。
二、MVCC 的核心目標：解決并發難題
在數據庫并發場景中，傳統的 “鎖機制” 會導致?讀寫互斥（讀操作加共享鎖，寫操作加排他鎖，兩者沖突），引發性能瓶頸。MVCC 的出現就是為了在 “并發控制” 與 “性能” 之間找到平衡，具體目標包括：
- 避免讀寫阻塞：讀操作（SELECT）無需等待寫操作釋放鎖，寫操作（UPDATE/DELETE/INSERT）也無需阻塞讀操作。
- 支持事務隔離級別：實現 MySQL 中的?Repeatable Read（可重復讀）?和?Read Committed（讀已提交）?隔離級別（InnoDB 默認使用 Repeatable Read，通過 MVCC 避免幻讀）。
- 提高并發吞吐量：減少鎖競爭，讓多個事務可以同時讀寫數據庫，提升系統整體處理能力。
通俗理解一下：可以把 MVCC 理解成數據庫的 “時光機” 機制，專門解決多個人同時操作數據時的沖突問題。
打個比方：你在看一本電子書（讀數據），同時另一個人在修改這本書的內容（寫數據）。沒有 MVCC 的話，你可能會看到亂七八糟的半成品內容，或者對方修改時你得一直等著不能看。
但有了 MVCC 就不一樣了：
數據庫會給每條數據拍 “快照”，你看書時翻到的是某一時刻的完整版本（快照讀），不受別人修改的影響；
別人修改時，會新建一個新版本的數據，舊版本依然保留給正在讀的人用；
等你看完（事務結束），舊版本可能會被悄悄清理掉，不占額外空間。
這樣一來，“讀” 和 “寫” 互不干擾，不用排隊等待，數據庫并發處理能力就大大提高了。這就是 MVCC 的核心作用 —— 通過保留數據的多個版本，讓讀寫操作能同時進行。
