【データベースロック】行ロックについて図解してみた

データベースロック　行ロックって実際どう動くの？MySQLで実験してみた！

データベースのロックについて知識として何となく理解しているものの、実際どういうふつにロックされているのか疑問に思ったことはありませんか？
今回は、DBのGUIツールを使って実際にロックを引き起こし、その挙動を体感してみたら面白かったので図を交えながら解説します。

そもそも行ロックってなに？

行ロックとは、データベースで更新対象の特定レコード(行)のみをロックし、他からの同時書き込みや改変を防ぐ仕組みです。テーブル全体をロックする方式と比べて競合が起きにくく、システムの同時並行処理を高めることができます。

この知識だけでも十分かもしれませんが今回は実際に体感してみましょう！

環境構築準備

今回使うDBはこちらです。
(category_idにはIndexをつけています。)

DBのGUIツールには MySQL Workbench を使用します。
ロックを引き起こすには2つのセッションが必要なため、図のように2つローカルでの接続を作っておきます。

• セッション1：localhost
• セッション2：localhost2

として進めていきます！！

実験開始！行ロックを体感してみよう

1.セッション1で特定の行をロックする

まずセッション1(localhost)で、以下のSQLを実行してトランザクションを開始します。

BEGIN;
UPDATE items SET stock = 45 WHERE item_id = 2;

これで item_id = 2のレコードがロックされました！
他のセッションからはこのitem_id = 2のレコードは更新ができないはずです。

図にするとこんな状態ですね。

2.セッション2で同じ行を更新してみる

次に、セッション2(localhost2)から同じitem_id = 2に更新をかけてみましょう。

BEGIN;
UPDATE items SET stock = 48 WHERE item_id = 2;
commit

こちらを実行すると・・・

処理が完了せず、ストップしました！
GUIのインジケーターがクルクル回ったままで、処理が終わらないことが確認できます。
これがロック待ちの状態です。

図にするとこんな感じです。

3.セッション1をコミットしてロックを解放する

それでは、待たせているセッション1の処理を完了させてロックを解放させましょう。

-- BEGIN;
-- UPDATE items SET stock = 45 WHERE item_id = 2;
commit

すると・・・・！
セッション1をコミットした瞬間に、セッション2のロックが解放され、データの更新が実行されます。

データを確認してみると、とitem_id = 2のstockが48に更新されており、セッション2の結果が反映されています。

まとめ

今回は、行ロックの仕組みについて図解と体験を交えて解説をしました。

答えがすぐ手に入るAI時代において自分で手を動かして腑に落ちるまで理解するという作業はとても大事だなと改めて思いました。

今後もデータベースのロックについてはまとめていこうと思うので乞うご期待！