MySQL 同時実行制御の原則に関する知識ポイント

Mysql は、高性能なデータ ストレージ サービスを提供する主流のオープン ソース リレーショナル データベースです。バックエンド開発を行うと、パフォーマンスのボトルネックが発生することがあります。これらのボトルネックは、アプリケーション自体ではなく、データベース レベルから発生する場合があります。

したがって、MySQL の基本原理のいくつかを習得すると、MySQL をより深く理解し、そのパフォーマンスを最適化するのに役立ちます。

これにより、高性能なバックエンド サービスが開発されます。

1. MySQL論理フレームワーク

mysql ロジック フレームワークの図は次のとおりです。

最上位層はクライアントからの接続を処理します。

主に接続処理、認可認証、セキュリティ等を担当します。 Mysql は、クライアントからの接続を処理するためにこのレイヤーでスレッド プールを維持します。 Mysqlはユーザー名とパスワードの認証を使用できます。

SSL は、X.509 証明書認証に基づいて使用することもできます。

2 番目のレイヤーは、クエリ キャッシュ、パーサー、オプティマイザーの 3 つの部分で構成されます。パーサーは SQL ステートメントを解析するために使用され、オプティマイザーは解析されたステートメントを最適化します。

クエリを解析する前に、サーバーはまずクエリ キャッシュをチェックします。対応するクエリ結果がその中に見つかった場合、クエリの解析や最適化などを実行する必要はなく、クエリ結果が直接返されます。ストアド プロシージャ、トリガー、ビューなどはすべてこのレイヤーで実装されます。

3 番目の層はストレージ エンジンで、MySQL へのデータの保存、データの抽出、トランザクションの開始などを担当します。ストレージ エンジンは、API を介して上位層と通信します。これらの API は、異なるストレージ エンジン間の違いを隠蔽し、これらの違いを上位層のクエリ プロセスに対して透過的にします。ストレージ エンジンは SQL を解析しません。 MySQL で最も一般的に使用されるストレージ エンジンは InnoDB です。

2. MySQLの同時実行制御

複数のスレッドが同時にデータを操作すると、同時実行制御の問題が発生する可能性があります。

2-1. 読み取り書き込みロック

複数のスレッドが単にデータを読み取っているだけの場合、実際には互いに影響を与えることなく一緒に読み取ることができます。このとき、「読み取りロック」(共有ロックとも呼ばれる) を使用する必要があります。

読み取りロックを取得したスレッドは互いにブロックされず、同時にリソースを読み取ることができます。

スレッドがデータを書き込む必要がある場合は、「書き込みロック」（排他ロックとも呼ばれる）を使用する必要があります。

書き込みロックは、書き込み操作が完了するまで他の書き込みロックと読み取りロックをブロックします。

2-2. ロックの粒度

まず、概念を明確にしましょう。特定のリソースに対して、ロックする必要があるデータが少ないほど、システムが処理できる同時実行性が高くなります。

しかし、ロックはリソースも消費します。システムがデータへのアクセスではなくロックの管理に多くの時間を費やすと、

システムのパフォーマンスに影響が出る可能性があります。

したがって、適切な「ロック戦略」とは、ロックのオーバーヘッドとデータのセキュリティのバランスを見つけることです。MySQL は複数のストレージ エンジン アーキテクチャをサポートしています。

各ストレージ エンジンは独自のロック戦略とロック粒度を実装できます。

2-3. テーブルロックと行ロック

名前が示すように、テーブル ロックはテーブル全体をロックします。テーブルロックのオーバーヘッドは比較的小さいです。テーブルに書き込みロックを追加すると、このテーブルに対する他のユーザーによるすべての読み取りおよび書き込み操作がブロックされます。

MySQL では、ストレージ エンジンが独自のロックを提供できますが、MySQL は ALTER TABLE ステートメントなどのテーブル ロックを使用する場合もあります。

書き込みロックは読み取りロックよりも優先度が高いため、書き込みロック要求は読み取りロック キューの先頭に挿入される場合があります。

行レベルのロックは行全体をロックするため、同時処理を最大限にサポートできますが、ロックのロック解除と追加のオーバーヘッドも比較的大きくなります。行レベルのロックは、ストレージ エンジン レベルでのみ実装されます。

すべてのストレージ エンジンは、独自の方法で行レベルのロックを実装します。

3. MVCC

MVCC は「Multi-version Concurrency Control (マルチバージョン同時実行制御)」の略です。これは行レベル ロックのバリエーションと考えることができますが、多くの場合、ロック操作を回避します。

したがってオーバーヘッドは低くなります。

主流のリレーショナル データベースはすべて MVCC を実装していますが、実装メカニズムは異なります。実際のところ、MVCC には統一された標準はありません。

しかし、それらのほとんどは非ブロッキング読み取り操作を実装しており、書き込み操作では必要な行のみがロックされます。

MVCC は、実行中に各トランザクションで表示されるデータの一貫性を保証します。

ただし、異なるトランザクションは異なる時間に開始されるため、同じテーブルに対して同時に表示されるデータは異なる場合があります。

MySQL の InnoDB エンジンでは、レコードの各行の後に 2 つの非表示列を保存することでこれを実現します。

1 つは行の作成時刻を保持し、もう 1 つは行の有効期限 (または削除時刻) を保持します。

実際に保存されるのは実際のタイムスタンプではなく、「システム バージョン番号」です。

トランザクションが開かれるたびに、システム バージョン番号が増加します。トランザクションが開始されると、システム バージョン番号がトランザクション バージョン番号として使用され、照会された行のバージョン番号と比較されます。

一般的な CRUD 操作でバージョン番号がどのように機能するかを次に示します。

入れる

現在のシステムバージョンを行バージョン番号として保存します

消去

現在のシステム バージョン番号をこのデータ行の「削除バージョン」に保存します。

アップデート

新しい行を挿入し、現在のシステム バージョン番号をフライト バージョン番号として保存し、現在のシステム バージョン番号を元の行の「削除されたバージョン」に保存します。

選択

現在のトランザクションのバージョンよりも前のバージョンの行のみを検索します。これにより、トランザクションによって読み取られる行がすでに存在するか、

トランザクション自体によって挿入または変更されます。

行の「削除バージョン」は未定義であるか、現在のトランザクション バージョン番号よりも大きいです。これにより、トランザクションによって読み取られた行が

取引前に削除されませんでした。

MVCC は、REPEATABLE READ および READ COMMITTED 分離レベルでのみ機能し、他の 2 つの分離レベルでは機能しません。

READ UNCOMMITTED は、現在のトランザクション バージョンに準拠するデータ行ではなく、常に最新のデータを読み取るためです。 SERIALIZABLE はすべての読み取り行をロックします。

以上がMySQLの同時実行制御原理の詳細内容です。追加事項がありましたら123WORDPRESS.COMの編集者までご連絡ください。