innodb的讀資料總是一致的，如果在session-1讀的過程中，session-2對資料進行修改，不管session-2是否提交，在session-1的事務中都會讀到修改前的值。讀操作保持一致性並不受阻塞的原因是多版本機制。所謂多版本機制是指innodb會儲存被修改資料的舊版本，以支援併發和回滾。多版本也決定了delete操作不會立刻導致資料從資料檔案移除，而是等事務log被清理的時候才刪除。多版本機制的關鍵是undo和redo事務日誌，每行為支援多版本包含3個域：
db_trx_id最近一次修改或者插入該行的事務號；這會決定某個select是否能獲取到某行資料；
db-roll-ptr指向undo日誌的操作；
db_row_id遞增的行版本號；
如果執行的不止是select操作，而是select for update，或者select for share lock，則會在對應的資料上加上lock，目前innodb支援3種鎖：
record lock，鎖定一條記錄，載入index上；
gap lock 鎖定乙個記錄區間，如果通過唯一性索引進行select則不會導致gap lock，因為record lock就夠了；
next key locks結合了上面兩種，用於搜尋並阻止「幻讀」，因為該鎖不僅能鎖住檢索到的行，還會鎖住該記錄前面的記錄集合，這樣如果加了鎖insert就不會成功。需要注意的是如果檢索的不是索引，或者沒有檢索到結果，lock會加在整個表上，導致其他的排它鎖不能申請成功。
這就要求我們在做update的時候必須以索引作為過濾條件，並且盡快結束。
Innodb事務和鎖總結
一.事務隔離級別 read uncommited 讀未提交，事務之間可以看到彼此之間正在修改的內容，會出現所謂的髒讀現象 read commited 讀已提交，只能讀取已經提交的事務修改的資料，不會出現髒讀的現象，但會出現不可重複讀和幻讀的情況 repeatable read 可重複度，在innod...
InnoDB 事務和併發控制相關的檔案
與事務管理和併發控制相關的檔案目錄結構 storage innobase btr b 樹索引結構，鎖物件施加在索引項上面，而不是直接施加在記錄 元組上面 btr0btr.cc 索引管理，索引的建立 釋放等相關操作 btr0bulk.cc 索引上資料的批量操作 btr0cur.cc 索引樹上遍歷對ro...
innodb事務日誌
mysql會最大程度的使用快取機制來提高資料庫的訪問效率，但是萬一資料庫發生斷電，因為快取的資料沒有寫入磁碟，導致快取在記憶體中的資料丟失而導致資料不一致怎麼辦？innodb主要是通過事務日誌實現acid特性 事務日誌包括 重做日誌redo和回滾日誌undo redo記錄的是已經全部完成的事務，就是...