REPEATABLE READの話 - NullPointer's
MySQL5系で、REPEATABLE READな環境があったのですが、ん？と思うことがあったので、備忘録。 結論から言うと、MySQL5.5 + InnoDBでファジーリードやファントムリードと思われる挙動が確認できた（気がする）。 InnoDBのREPEATABLE READでハマった話 - カイワレの大冒険 Second これ、厳密にはファジーリードとは言えないのですよ。ちょっと見ていきましょうか。 まず、複数トランザクションが同一の行をupdateした場合の挙動は、公式リファレンスマニュアルに書いてあります。 テーブル内のいくつかの行を更新すると、SELECT は他の行の古いバージョンを確認すると同時に、更新された行の最新のバージョンを確認します。もし別のユーザが同時に同じテーブルを更新すると、今までとは違う状態のテーブルをデータベース内で確認するかもしれないいう例外があるかもしれ
InnoDBのREPEATABLE READにおけるLocking Readについての注意点
本日は、MySQL Casual Advent Calendar 2013の20日目である。というわけでカジュアルに小ネタを紹介しよう。 MVCC - Multi Version Concurrency Controlご存知の通り、InnoDBはMVCCを実装している。そのため、分離レベルがREPEATABLE READの場合には、行にロックをかけることなく、一貫した読み取りが可能になっている。 もし、あるトランザクションT1開始後に、別のトランザクションT2によって同じ行が書き換えられてしまった場合には、T1はロールバックセグメントにある古いバージョンの値を読み取ることができるので、T1内で実行したSELECTは常にT1開始時点のデータを参照することができるのである。大事なのでもう一度言うが、REPEATABLE READにおける単純なSELECTでは行ロックは必要ない。 Lost Up
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
