初心者がソースコードからMySQLのデッドロック問題を理解する

夜遅くまで何度も困難なシングルステップデバッグを行った後、ようやく理想的なブレークポイントを見つけました。ロック取得プロセスコードの大部分は、 lock0lock.cのstatic enum db_err lock_rec_lock()関数にあることがわかります。この関数は、ロック取得のプロセスと、ロック取得が成功したかどうかを表示します。

シナリオ 1: 主キーによる削除

テーブル構造

テーブル `t1` を作成します (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `name` varchar(10) NOT NULL デフォルト ''
 主キー (`id`)
)ENGINE=InnoDB;

id = 10 の t1 から削除します。

ご覧のとおり、インデックス PRIMARY はロックされており、モードは 1027 です。1027 はどういう意味でしょうか? 1027 = LOCK_REC_NOT_GAP + LOCK_X (非ギャップレコードロックとXロック)

プロセスは以下のとおりです

結論:主キー ID に基づいて他のインデックスを使用せずにデータを削除するには、この SQL ステートメントで、ID = 10 のレコードの主キーインデックスに X ロックを追加するだけで済みます。

シナリオ 2: 一意のインデックスによる削除

テーブル構造が若干調整され、名前の一意のインデックスが追加されました。

データを構築する CREATE TABLE `t2` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `name` varchar(10) NOT NULL デフォルト ''
 主キー (`id`)、
 ユニークキー `uk_name` (`name`)
） ;
`t2` (`id`, `name`) 値に挿入 
 (1,'M')、
 （２、'Y'）、
 （３、'S'）、
 （4,'Q'）、
 （５、'L'）；
 
テスト SQL ステートメント delete from t2 where name = "Y"

実際のソースコードのデバッグ結果を見てみましょう

最初のステップ:

ステップ2:

結論:このプロセスでは、まずユニークキーuk_nameにXロックを追加し、次にクラスター化インデックス(主キーインデックス)にXロックを追加します。

プロセスは以下のとおりです

シナリオ3: 通常のインデックスによる削除

データを構築する CREATE TABLE `t3` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `name` varchar(10) NOT NULL デフォルト ''
 主キー (`id`)、
 キー `idx_name` (`name`) 
);
`t3` (`id`, `name`) 値に挿入 
 (1,'N')、
 （２、'G'）、
 （3、「私」）、
 (4,'N')、
 （5、'X'）；
 
テストステートメント:
name = "N" の場合、t3 から削除します。

デバッグのプロセスを図に示します。

結論:共通インデックスを介して更新する場合、条件を満たすすべての共通インデックスに X ロックが追加され、関連する主キーインデックスに X ロックが追加されます。

プロセスは以下のとおりです

シナリオ4: インデックスを使用せずに削除する

テーブル `t4` を作成します (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `name` varchar(10) NOT NULL デフォルト ''
 主キー (`id`)
）

`t4` (`id`, `name`) 値に挿入 
 (1,'M')、
 （２、'Y'）、
 （３、'S'）、
 （4,'Q'）、
 （５、'L'）；
 
name = "S" の場合、t4 から削除します。