MySQL データベースで SQL が実行される仕組み

今日は、mysql ビデオ チュートリアル 列を使用して、update ステートメントの実行プロセスを見てみましょう。

#クエリ文と更新文の一連の実行処理も同様のステップを経ます。記事の写真を簡単に見てみましょう:

" class="lazyload" src="https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d529960ec1dd496ca90860641bcaa093~tplv-k3u1fbpfcp-watermark.image?x-oss-process=image/resize,p_40" data-width="800" data- style="max-width:90%"/>

まず、ステートメントを実行する前にデータベースに接続する必要があります。これは、最初のステップ: テーブルが更新されると、このテーブルに関連するクエリ キャッシュが無効になるため、通常は 10 月のクエリ キャッシュは推奨されません。

次に、アナライザーは構文分析と字句分析を実行します。これが更新ステートメントであることがわかった後、オプティマイザーは使用するインデックスを決定し、次にエグゼキューターが特定の実行を担当します。まずこれを見つけます。行、アップデートを実行します。

クエリ ステートメントの更新とは異なり、更新プロセスには 2 つの重要なログも含まれます。これについては前の記事でも紹介しました。興味がある場合は、先週の記事「MySQL の 2 つの」ログ システムを参照してください。 』については、ここではあまり紹介しません。

簡単な例を通じて更新操作プロセスを分析してみましょう。

まず主キー ID と整数フィールド c:

mysql> create table demo T (ID int primarty ,c int);复制代码

を持つテーブルを作成します。次に、ID=2

mysql> update table demo set c = c + 1 where ID = 2;复制代码

## の行の値に 1 を加算します。 #Next update ステートメントの実行プロセスを見てみましょう。図の明るいボックスはストレージ エンジンでの実行を表し、色付きのボックスはエグゼキューターでの実行を表します。

最後に、redolog を作成する際に、準備とコミットという 2 つのステップがあることがわかります。これは、よく「2 フェーズ コミット」と呼ばれるものです。

ログに「2 段階の送信」が必要なのはなぜですか?

REDO ログと binlog はそれぞれストレージ エンジンとエグゼキューターのログであるため、2 つの独立したロジックです。2 段階の送信を使用しない場合、どちらを先に送信しても問題が発生します。そしてどれを後で提出するか。上の例を見てみましょう。ID=2 の行の現在の値が 0 であるとします。更新プロセス中に最初のログが書き込まれた後、2 番目のログが書き込まれていない間にクラッシュが発生します。どうなりますか? ?

最初に redolog を書き込み、次に binlog
• を書き込みます。 redolog は書き込まれましたが、binlog はまだ書き込まれておらず、MySQL プロセスが異常に再起動したとします。 redolog が書き込まれた後は、システムがクラッシュした場合でもデータを復元できることがわかっているため、MySQL が再起動されると、この行は 1 に復元されます。バイナリログは完了する前にクラッシュするため、現時点ではバイナリログにそのようなステートメントは存在せず、後でログをバックアップするときに、保存されたバイナリログログにはこのステートメントは含まれません。 binlog を介してデータを復元する必要がある場合、binlog はこのステートメントを失っているため、復元された行の値は 0 となり、元のデータベースの値とは異なります。
最初に binlog を書き込み、次にログをやり直します
• 。バグログを書き込んだ後、REDO ログが完了する前にクラッシュが発生し、この時点でデータベースがクラッシュすると、回復後にトランザクションが無効になるため、この行の値は 0 のままですが、更新ステートメントは記録されています。 binlog.log にある、将来データを復元するために binlog を使用する必要がある場合は、追加のトランザクションが発生します。この update ステートメントを実行して、値を 0 から 1 (元のデータベースの 0 とは異なる) に更新します。
「2 フェーズ コミット」を使用しない場合、データベースの状態はログを使用して復元されたデータベースと不一致になることがわかります。データの回復にログを使用する可能性は比較的低いですが、ログの最も一般的な使用法は、フル バックアップとバイナリ ログによって実現される容量拡張時であり、これによりオンラインのマスター/スレーブ データベース間で不整合が発生する可能性があります。

関連する無料学習の推奨事項:

mysql ビデオ チュートリアル

以上がMySQL データベースで SQL が実行される仕組みの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。