mysql-innodb-事務

寫在最前

這是讀書筆記,Mysql,innodb系列一共3篇。mysql

ACID

  • A:原子性,要麼成功,要麼失敗
  • C:一致性,事務將數據庫從一種狀態轉換爲另外一種穩定狀態,不違反約束條件
  • I:隔離性,多個事務互不影響
  • D:持久性


事務的隔離級別

隔離級別 說明
READ UNCOMMITTED 未提交讀,會形成髒讀,違反持久性D
READ COMMITTED 讀已提交數據, 會形成幻讀 違反一致性C
REPEATABLE READ 可重複讀,默認隔離級別
SERIALIZABLE 不會使用mysql的mvcc機制,而是在每個select請求下得到讀鎖,在每個update操做下嘗試得到寫鎖

SELECT@@global.tx_isolation查看全局事務隔離級別sql

事務的實現

Force Log at Commit機制

  • 當事務提交時,必須先將該事務的全部日誌寫入到日誌文件進行持久化,以後進行COMMIT操做完成。
  • 日誌寫入日誌文件時,日誌緩衝先寫入文件系統緩存,爲了確保寫入磁盤,須要調用一次fsync操做。
  • 因爲fsync的效率取決於磁盤的性能,所以磁盤的性能決定了事務提交的性能,也就是數據庫的性能。

3種日誌文件

redolog

概念

實現事務的持久性
InnoDB存儲引擎層產生,物理日誌,記錄的是對頁的修改,innodb1.2版本後,最大512GB
一個事務多個日誌記錄,每一個事務內部是順序寫的。併發寫入多個事務的日誌,不隨事務提交順序寫入
兩部分:重作日誌緩衝(redo log buffer)易失的;重作日誌文件(redo log file),持久的

log buffer刷新策略

由innodb_flush_log_at_trx_commit控制




innodb_flush_log_at_trx_commit值 說明
0 提交時,不寫入日誌文件
1 默認值,提交時調用一次fsync操做
2 提交時寫日誌文件,不進行fsync操做

log buffer刷新到磁盤的規則

  • 事務提交時
  • log buffer已經有一半空間被使用
  • log checkpoint時

innodb恢復時如何使用redolog

checkpoint存儲了已經刷新到磁盤頁上的LSN,因此僅需恢復checkpoint開始的日誌部分
innodb,順序讀取,並行操做,提升性能
物理日誌,冪等的,恢復快
LSN存儲了checkpoint的位置。

undolog

基本概念

  • 存儲在undo段中,位於共享表空間,邏輯日誌
  • 支持mvcc,支持回滾
  • undolog 會生產redo log
回滾時,undo生產反向操做,insert對應delete,delete對應一條insert,update對應一個反向update

格式

類型 說明
insert undo log insert產生,事務自己可見,其餘事務不可見,commit後直接刪除
update undo log
delete,update產生,其餘事務可見,commit後放入列表中,供purge操做
比insert undo log大

commit後

undo加入history list中,供後續purge操做
判斷undo頁 的使用空間是否小於3/4,是新的undo log 記錄到老的undo log後邊

binlog

MySQL數據庫的上層產生的,而且二進制日誌不單單針對於InnoDB存儲引擎,
邏輯日誌,記錄的是SQL語句
事務提交後一次性寫入

purge

purge是清理的delete和update以前行記錄的版本。
從history list中找undo log,而後再從undo page中找undo log,防止大量隨機讀寫,提升性能
相關參數
innodb_purge_batch_size設置每次須要purge清理的undo page數量,innodb1.2之後默認爲300
innodb_max_purge_lag用來控制history list的長度,默認值爲0,不作任何限制
大於0,延後DML操做,對每行數據延緩:
delay=((length(history_list)- innodb_max_purge_lag)*10)-5 複製代碼

group commit

提升磁盤fsync的效率,一次刷新多個事務日誌文件

綜述:5.7版本innodb開啓binlog的commit過程

注意:
THD是MySQL server層最核心的類
LSN:
日誌序列號
重作日誌寫入的總量
checkpoint的位置
頁的版本
相關文章
相關標籤/搜索