MySQL データベースで SQL が実行される仕組み
- coldplay.xixiオリジナル
- 2020-11-09 17:20:221844ブラウズ
今日は、mysql ビデオ チュートリアル 列を使用して、update ステートメントの実行プロセスを見てみましょう。
" class="lazyload" src="https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d529960ec1dd496ca90860641bcaa093~tplv-k3u1fbpfcp-watermark.image" data- style="max-width:90%" data- style="max-width:90%">
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 サイトの他の関連記事を参照してください。
声明：
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。