寫在最前
這是讀書筆記,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的位置
頁的版本