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
transactionの途中でトランザクションが切れてしまった時にそのトランザクションを殺す方法 - Garbage in, gospel out
起こったこと transactionモードで作業途中、セッションが切れた。 そのとき特定tableにinsertをしたがcommitしていない状態だった。 後ほど再度そのtableをselectしたが、当然commitしていないのでデータがなかった。 しかしinsertしようとすると、 ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction というエラーが表示され失敗した。 原因 transactionがロックを取得したまま放置状態になっていたために発生した。 対処 基本方針は show processlist; と show innodb status; の結果を見比べてそれっぽいthread見つけて kill [thread id] する。 show processlist; してみると、今回
LOCK IN SHARE MODE の使いドコロを間違えてデッドロック - ngyukiの日記
先日、作っていたシステムでデッドロックがわりかし頻繁に発生することが判りました。 RDBMS のデッドロックは必ずしもバグでは無く、無理に対応するよりアプリケーション側でハンドリングしてトランザクションのリトライなどを行った方がいい場合もあると思いますが、このケースでは明らかにバグでした。 デッドロックするクエリ テーブル定義は次の通りで・・・ CREATE TABLE tt ( id INTEGER NOT NULL PRIMARY KEY, no INTEGER NOT NULL ); INSERT INTO tt VALUES (1, 0); 次のようなSQLで更新します。 BEGIN; /* (1) */ SELECT @no := no FROM tt WHERE id = 1 LOCK IN SHARE MODE; /* (2) */ UPDATE tt SET no = @n
MySQL - InnoDBのロック関連まとめ - Qiita
メモ開放。InnoDBの行ロック関連について、それぞれの項目が必ずしも並列関係にあるわけではないが、以下のようにまとめていく。 排他ロックと共有ロック SELECT ~ FOR UPDATE SELECT ~ LOCK IN SHARE MODE 排他ロックと共有ロック 読み取りを許すかどうかの違い。排他ロックは対象行を全てのクエリからロックするため、UPDATEやDELETEなどの更新クエリはもちろん、SELECTなどの読み取りクエリも通さない。共有ロックは更新クエリを通さないが、読み取りクエリは通す。 （追記：排他ロックは分離レベルによってはSELECTを通すとのこと。 公式 ） 排他ロックは全てのクエリを通さず、共有ロックは排他ロックを伴うクエリを通さない、と言い換えたほうがいいかもしれない。 公式では共有ロックは同トランザクション内のselectを許し、排他ロックは同トランザクショ
ElixirでSI開発入門 #2 Ectoで楽観的ロック - Qiita
（この記事は、「Elixir or Phoenix Advent Calendar 2017」の9日目です） fukuoka.exのメンバーにより連載されています。 昨日は、@piacere さんの「ExcelでElixirマスター2回目：「列の抽出」と「Web表示」でした 今日は、実際のプロダクト開発のお話２回目です。 はじめに Elixirで実際にプロダクト開発した経験からサンプルコードを交えて解説する本連載 基本となるデータベース排他制御の後編は、 Webサービスなどでより一般的な楽観的ロックです。 悲観的ロックと楽観的ロックに関する一般的な解説は例によってこちらの記事をお勧めします。 -> 排他制御（楽観ロック・悲観ロック）の基礎 本連載の前回記事はこちら |> ElixirでSI開発入門 #1 Ectoで悲観的ロック Ecto.Changeset.optimistic_lock(
MySQL InnoDBのネクストキーロック おさらい - SH2の日記
MySQLのInnoDBストレージエンジンは行ロックをサポートしています。しかしOracleと同じ感覚でアプリケーションを作っていると、思わぬところでデッドロックに出くわすことがあります。これはInnoDBのロック範囲がOracleよりも微妙に広いためです。 実際の例で確認してみましょう。 mysql> select * from t; +----+------+ | c1 | c2 | +----+------+ | 10 | a | | 15 | a | | 20 | a | | 25 | a | | 30 | a | | 35 | a | | 40 | a | | 45 | a | | 50 | a | +----+------+c1列は主キーになっています。1つめのセッションで以下のSQLを実行します。 mysql> set tx_isolation = 'repeatable-r
InnoDBのロックの範囲とネクストキーロックの話 - かみぽわーる
この記事はMySQL Casual Advent Calendar 2013 3日目の記事です。 はじめに 以前にSELECT ... FOR UPDATEとロックの挙動 - walf443's blogの記事にTwitterで少し言及したんですが、それの補足というか、InnoDBのロックの範囲について僕はこう理解していますよという話です。 MySQLといえば、InnoDBをネットワークサーバとして使うためのフレームワークであり、SQLはInnoDBのインデックスにアクセスするためのDSLといっても過言ではないでしょう。 InnoDBのロックとはつまるところインデックス行のロックなので、InnoDBのロックの範囲を理解するためにInnoDBのインデックスについて少し前置きしておきます(だいぶ端折ったけど長くなった…)。 クラスタインデックスとセカンダリインデックス すでにInnoDBのイン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL :: MySQL 8.4 Reference Manual :: 17.7.2.4 Locking Reads
Advisory Locks and How to Use Them