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

今日は、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);复制代码

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

最後に、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 サイトの他の関連記事を参照してください。