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

[minoton]

このあたりの動作はRDBMSによって、同じ用語で説明がされていても違うことがある。マニュアルを熟読する、振る舞いを調べるしかなさそう

[yuya_presto]

すっかり慣れたけど、REPEATABLE READでも、SELECT FOR UPDATEやUPDATE/DELETEはBEGIN以後に別トランザクションでCOMMITされた内容を読み取る仕様という話。なおPostgreSQLは代わりにlost updateを検知。

[rugamaga]

今更ハマった記念

[uzuki05]

Locking Read ではファントムが発生する

[castaneai]

“InnoDBのNon-Locking Read/REPEATABLE READではネクストキーロックによって防いでくれるファントムも、Locking Readでは発生してしまう。Locking ReadはREAD COMMITTED相当の挙動になると考えて貰えれば差し支えない”

[slash_01]

やっぱDB周りはこのブログや。

[mapawata]

REPEATABLE READで良いという話

[ymm1x]

LostUpdate

[ttanimichi]

MVCC の詳しい記事

[k-holy]

InnoDBの分離レベル

[okbm]

どハマりしたのでブクマ

[oasis440]

“MVCC”

[masa_matya]

lock周り

[masudaK]

絶対熟読しまくる。

[tmatsuu]

分離レベルとロックは分かった気でいるが多分ちゃんと理解できてない。奥が深すぎてツライ。

[kamipo]

REPEATABLE READとは何だったのか

[ikosin]

<pre>の使い方が面白い

[sh2]

一つのシステム内で、処理によってトランザクション分離レベルを変更した事例をまだ見たことがないです。個々の開発者の権限で変更できたら阿鼻叫喚だし…

[kimutansk]

こういう風に時系列にSQLを図示するととりあえず理解はしやすいですねぇ

[elf]

カジュアルとか書いているけど気を付けないとこれはハマりそうだ #mysql #knowhow #matome #nippondanji