Springboot設定事務隔離等級：
1、@EnableTransactionManagement 來啟用注解式事務管理
2、@Transactional（isolation = Isolation.DEFAULT，propagation = Propagation.REQUIRED）設定事務隔離級別和傳播行為
這兩篇文章可以結合起來一起理解：
面試官：談談你對Mysql的MVCC的理解？
這一篇我覺得是寫MVCC寫的最好的一篇：
Innodb中的事務隔離級別和鎖以及MVCC之間的關系
MVCC的意義只是替代讀鎖，寫依舊是加鎖的，這樣避免了臟寫
MVCC不可以避免幻讀，（但是有的文章說mvcc防住了幻讀，沒防住是因為把快照讀提升到了當前讀的模式）
如果要避免幻讀，可以使用MVCC+間隙鎖的方式，
MySQL 到底是怎么解決幻讀的？
快照(ReadView)讀的幻讀-mvcc 解決
當前讀的幻讀-Next-Key鎖解決
當前讀與快照讀：
首先讀分為：
快照讀
select * from table where ?;
當前讀：特殊的讀操作，插入/更新/洗掉操作，屬于當前讀，需要加鎖，
select * from table where ? lock in share mode;
select * from table where ? for update;
insert into table values (…);
update table set ? where ?;
delete from table where ?;
對于快照讀來說，幻讀的解決是依賴mvcc解決，而對于當前讀則依賴于Next-Key鎖解決，
MySQL事務隔離級別和實作原理（看這一篇文章就夠了！）：
MySQL 中是如何實作事務隔離的：
- 首先說讀未提交，它是性能最好，也可以說它是最野蠻的方式，因為它壓根兒就不加鎖，所以根本談不上什么隔離效果，可以理解為沒有隔離，
- 再來說串行化，讀的時候加共享鎖，也就是其他事務可以并發讀，但是不能寫，寫的時候加排它鎖，其他事務不能并發寫也不能并發讀，
- 最后說讀提交RC和可重復讀RR，是采用了MVCC (多版本并發控制)的方式
- RR級別在一般的標準上是不能解決幻讀，但是在Mysql里面已經解決了RR級別幻讀的問題：
并發寫的時候加鎖問題：
加鎖的程序要分有索引和無索引兩種情況，比如下面這條陳述句
update user set age=11 where id = 1
id 是這張表的主鍵，是有索引的情況，那么 MySQL 直接就在索引數中找到了這行資料，然后干凈利落的加上行鎖就可以了，
而下面這條陳述句
update user set age=11 where age=10
表中并沒有為 age 欄位設定索引，所以， MySQL 無法直接定位到這行資料，那怎么辦呢，當然也不是加表鎖了，MySQL 會為這張表中所有行加行鎖，沒錯，是所有行，但是呢，在加上行鎖后，MySQL 會進行一遍過濾，發現不滿足的行就釋放鎖，最終只留下符合條件的行，雖然最終只為符合條件的行加了鎖，但是這一鎖一釋放的程序對性能也是影響極大的，所以，如果是大表的話，建議合理設計索引，如果真的出現這種情況，那很難保證并發度，
mysql在RR隔離級別下有MVCC，那還有共享鎖嗎？
回答一：對于具備多版本控制能力的資料庫引擎確實不需要對表的讀取加鎖, MVCC能保障讀取的完整性. MVCC 僅于單行(或單個欄位)起作用, 鎖可以實作多行多表多操作的事務鎖定. 鎖用途和 MVCC 是不太一樣的, 可以說事務的實作依賴于 MVCC 特性, 但事務要比 MVCC 本身復雜得多. 如果不希望在讀取時記錄被修改, 鎖才是唯一可行的，
回答二：共享鎖還是存在的哦，在mysql5.6 innodb，RR隔離級別中，
使用主鍵索引去查詢一條不存在的資料，就會加上s鎖了，
你可以試一下：
開啟兩個事務用主鍵查詢同一條不存在資料（使用select … for update），
兩個事務都會回傳一個空結果，
此時，兩個事務無論是誰都沒辦法以這個主鍵insert資料，
深入分析事務的隔離級別----非MySQL的處理方法，標準SQL事務規定的處理方法，用鎖處理的
Redo log, bin log, Undo log
InnoDB中通過undo log實作了資料的多版本，而并發控制通過鎖來實作，
undo log除了實作MVCC外，還用于事務的回滾，MySQL Innodb中存在多種日志，除了錯誤日志、查詢日志外，還有很多和資料持久性、一致性有關的日志，
binlog，是mysql服務層產生的日志，常用來進行資料恢復、資料庫復制，常見的mysql主從架構，就是采用slave同步master的binlog實作的, 另外通過決議binlog能夠實作mysql到其他資料源（如ElasticSearch)的資料復制，
redo log記錄了資料操作在物理層面的修改，mysql中使用了大量快取，快取存在于記憶體中，修改操作時會直接修改記憶體，而不是立刻修改磁盤，當記憶體和磁盤的資料不一致時，稱記憶體中的資料為臟頁(dirty page)，為了保證資料的安全性，事務進行中時會不斷的產生redo log，在事務提交時進行一次flush操作，保存到磁盤中, redo log是按照順序寫入的，磁盤的順序讀寫的速度遠大于隨機讀寫，當資料庫或主機失效重啟時，會根據redo log進行資料的恢復，如果redo log中有事務提交，則進行事務提交修改資料，這樣實作了事務的原子性、一致性和持久性，
undo log: 除了記錄redo log外，當進行資料修改時還會記錄undo log，undo log用于資料的撤回操作，它記錄了修改的反向操作，比如，插入對應洗掉，修改對應修改為原來的資料，通過undo log可以實作事務回滾，并且可以根據undo log回溯到某個特定的版本的資料，實作MVCC，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/251727.html
標籤：其他