MySQL鎖系列（四）之 undo log

1) redo 記錄的是對頁的重做日誌，undo 記錄的是對事務的逆向操作

2) undo 會產生redo，undo的產生也會伴隨這redo的產生，因為重啟恢復的時候，可以通過redo還原這些undo的操作,以達到回滾的目的

1) 用於對事務的回滾

2）用於mvcc

* 在mysql5.1的年代，乙個mysql例項，就只有乙個rollback segment

* 在mysql5.1+ 的年代，乙個mysql例項裡面，可以有128個rollback segment

* 乙個segment 有 1024 個 undo slot，乙個undo slot 對應乙個undo log

* 乙個事務(dml)對應乙個undo log

據此推斷： 1) 5.1 最多能夠承載的併發事務（dml），1 * 1024 = 1024 2）5.1+ 最多能夠承載的併發事務（dml），128 * 1024 = 10w左右

從此可以看出，5.1 之後的版本支援的併發寫入事務數更多，效能更好

1) insert操作產生的undo

2）為什麼要單獨出來，因為insert的undo可以立馬釋放(不需要purge)，不需要判斷是否有其他事務引用，本來insert的事務也沒有任何事務可以看見它嘛

1）delete 或者 update 操作產生的undo日誌 2）判斷undo是否可以被刪除，必須看這個undo上面是否被其他事務所引用

3) 如果沒有任何事務引用，那麼可以由後台執行緒purge掉這個undo

1. 每乙個undo log中都有乙個db_trx_id , 這個id記錄的是該undo最近一次被更新的事務id

2. 如果這個id 不在readview(活躍事務列表) 裡面，就可以認為沒事務引用，即可刪除？

1) 5.6之前的版本，undo都是存放在ibdata，也就是所謂的共享表空間裡面的

2) 5.6以及之後的版本，可以配置存放在單獨的undo表空間中

1) delete語句操作的後，只會對其進行delete mark，這些被標記為刪除的記錄只能通過purge來進行物理的刪除，但是並不**空間

2）undo log，如果undo 沒有任何事務再引用，那麼也只能通過purge執行緒來進行物理的刪除，但是並不**空間

1) undo page裡面可以存放多個undo log日誌

2）只有當undo page裡面的所有undo log日誌都被purge掉之後，這個頁的空間才可能被釋放掉，否則這些undo page可以被重用

1. 對於delete --需要undo繫結該記錄才能進行回滾，所以只能打上標記，否則undo指向**呢 delete mark 2. 對於update --原記錄可以物理刪除，因為可以在新插入進來的地方進行undo繫結 * 如果不能原地更新： delete(注意：這裡是直接delete,而不是delete mark) + insert

* 如果可以原地更新，那麼直接update就好

1. 對於delete --不能直接被物理刪除，因為二級索引沒有undo，只能通過打標記，然後回滾。否則如果被物理刪除，則無法回滾 delete mark 2. 對於update --不能直接被物理刪除，因為二級索引沒有undo，只能通過打標記，然後回滾。否則如果被物理刪除，則無法回滾

delete mark + insert

MySQL鎖系列（四）之 undo log

MySQL系列之鎖

Mysql系列之鎖機制

MYSQL系列之鎖與死鎖

MySQL鎖系列（四）之 undo log

MySQL系列之鎖

Mysql系列之鎖機制

MYSQL系列之 鎖與死鎖

相關推薦

MYSQL系列之鎖與死鎖