MySQL の行ロック、ページ ロック、テーブル ロックの簡単な紹介

MySQL は、ロックの粒度に応じて行ロック、ページ ロック、テーブル ロックに細分化できます。

行ロック

1. 行ロックのロック粒度は MySQL で最も細かく、InnoDB ストレージ エンジンに適用され、現在の行のみが追加されます。ロック操作。同時実行の場合、ロック待機の可能性は低く、より多くの同時実行がサポートされますが、オーバーヘッドが高く、ロックが遅く、デッドロックが発生する可能性があります。

2. InnoDB で行ロックを使用するには前提条件があります。データを取得するときはインデックス付けが必要です。 InnoDB はインデックスのインデックス エントリをロックすることで行ロックを実装しているためです。

3. InnoDB はインデックス条件なしでクエリを実行するときにテーブル ロックを使用するため、同時実行性が高い場合に多数のロック競合が発生する可能性があります。さらに、この場合、異なるレコードにアクセスしても、同じインデックス項目が使用されるため、ロックの競合が発生する可能性があります。

ヒント: インデックス取得を使用する場合、必ずしも行ロックを使用する必要はありません。テーブル ロックも使用できます。 MySQL はさまざまな実行プランのコストを比較するため、インデックスよりもテーブル全体のスキャンの方が効率的である場合、InnoDB はテーブル ロックを使用します。したがって、SQL 実行計画と組み合わせてロックの競合を分析する必要があります。

4. 行ロックでは、主に主キー インデックスのロックと非主キー インデックスのロックの 2 つのステップに分けてロックが段階的に取得されるため、デッドロックが発生します。たとえば、2 つのトランザクションが同時に実行される場合、1 つは主キー インデックスをロックして他のインデックスを待機し、もう 1 つは非主キー インデックスをロックして主キー インデックスを待機します。デッドロックが発生します。 InnoDB は通常、この種のデッドロックを検出し、1 つのトランザクションでロックを解放してロールバックし、別のトランザクションでロックを取得してトランザクションを完了します。

テーブル ロック
テーブル ロックのロック粒度は MySQL で最も粗く、InnoDB および MyISAM エンジンに適用され、現在のテーブル全体をロックします。これは同時実行性の高いシナリオには適していませんが、オーバーヘッドが低く、ロックが速く、デッドロックがなく、ロック競合の可能性が最も高くなります。

ページ ロック
ページ ロックの粒度は行ロックとテーブル ロックの間であり、同時実行性は平均的で、コストとロック速度も平均的です。行ロックとテーブルロックの間。

以上がMySQL の行ロック、ページ ロック、テーブル ロックの簡単な紹介の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。