mysql(InnoDB)トランザクション独立性レベル(REPEATABLE READ)とロック、MVCC
REPEATABLE READ
(繰り返し読み可能)以前には、この独立性レベルが 解決 解決
の上で MySQLは、トランザクション独立性レベルRead committed、Repeatable Readの下で、InnoDBストレージエンジンは 読み取りは書き込みに影響しません:データが読み取り操作を実行している場合、他のトランザクションの書き込み操作は、現在のトランザクション行のSロックの解放を待つのではなく、行のスナップショットデータを読み取ります. 書き込みは読み取りに影響しません.データが書き込み中である場合、他のトランザクションの読み取りは、現在のトランザクションラインのXロックの解放を待つのではなく、ローのスナップショットデータを読み取ります.
だからまとめてみると、 を参照することができる.
(繰り返し読み可能)
(もちろん、
も解決できる)を解決できることが分かっていたが、単純にロックで実現すれば、以下のようになる可能性がある.REPEATABLE READ
独立性レベルでは、
、
の問題を解決できます.つまり、他のトランザクションがコミットしたレコードのみをトランザクションに読み込むことができ、同じトランザクションで複数回読み取るデータが他のトランザクションによって変更されても一貫していることを保証することができます.
:考えてみてください.トランザクションAでデータDを読み取るとき、Dが以前にトランザクションBに存在し、トランザクションBでデータDを修正したと仮定しますが、トランザクションBがまだ完了していません(commit/rollback)、トランザクションAがデータDを読み取ることができないようにするにはどうすればいいですか.トランザクションBがデータDに書き込みを行う場合、データDに行レベルの排他ロック(X lock)を加えたと仮定すると、トランザクションAは、トランザクションAが完了するまでデータDを読み取ることができず、
を解決する.
:考えてみてください.トランザクションAで初めてデータDを読み取った後、直接このデータDにS共有ロックを加えると、他のトランザクションは当然、トランザクションAが完了してからデータDを修正することができます.そうすれば、
を解決し、トランザクションAで何度もデータDを読み取ることができます.同じです.S +X
を使って確かにREAD COMMITTED
の隔離レベルの効果を実現することができて、
と
を避けて、もちろん、ここの問題は依然として低効です!!!
の
を採用しています.つまり、データを読み取るにはロックをかけず、MVCCの
モードを採用しています.そのため、InnoDBのやり方は、読むことは書くことに影響しません.書くことは読むことに影響しません.READ UNCOMMITTED
とREPEATABLE READ
の2つの独立性レベルはいずれも + MVCC
を使用しており、違いはMySQL-InnoDB-VCCマルチバージョン同時制御