SQL update 文の実行
1, update T set c=c+1 where ID=2;
1) update 文の流れはクエリ文と同じで、まずデータベースに接続します;
2)テーブル、関連テーブルの更新 クエリ キャッシュが無効になり、テーブルに関連するキャッシュされた結果がクリアされます; 3) アナライザーが
構文を分析し、その構文が更新ステートメントであると判断します;
4) オプティマイザーが決定しますどのインデックスを使用するか;
5) エグゼキュータはステートメントを実行し、更新するターゲット行を見つけます。
2. クエリ プロセスとは異なり、更新プロセスには、REDO ログ (REDO ログ) と binlog (アーカイブ ログ) という 2 つの重要なログ モジュールも含まれます。
1) MySQL のすべての更新操作はディスクに書き込まれる必要があり、ディスクも更新前に対応するレコードを見つける必要があります。プロセス全体の IO コストと検索コストが非常に高いため、MySQL は WAL (Write-Ahead) を使用します。 Logging) テクノロジ。最初にログを書き込み、次にディスクに書き込みます。
2) レコードを更新する必要がある場合、InnoDB エンジンはまずレコードを REDO ログに書き込み、メモリを更新します。同時に、InnoDB エンジンは適切なタイミングで REDO ログ内のレコードをディスクに更新します。システムのアイドル時間など。
ログモジュール REDO ログと binlog
1. InnoDB の REDO ログはサイズが固定されており、最初から書き込みを開始し、最後まで書き込み、その後最初に戻ってループで書き込みます。 write pos は現在の書き込み位置とチェックポイントを記録します消去位置を記録します。
1) 書き込み位置とチェックポイントの間は新たな操作を記録できますが、書き込み位置がチェックポイントに追いつくと新たな更新ができなくなりますので、消去位置の記録をデータファイルに更新し、実行後に記録する必要があります。消去操作 新しい操作。
2) REDO ログを使用すると、InnoDB はデータベースが異常に再起動した後でも操作記録が失われないことを保証できます。これはクラッシュ セーフと呼ばれます。
2. REDO ログは InnoDB エンジンに固有のログであり、binlog はすべてのエンジンで使用できるサーバー層のログです。
1) REDO ログはデータ ページの変更を記録する物理ログであり、binlog はステートメントの元のロジックを記録する論理ログです。2) REDO ログは循環書き込みであり、binlog は追加されます
。書き込みでは、以前のログは上書きされません。
3. binlog はすべての論理操作を記録し、追加書き込みの形式を採用します。システムがデータベース全体を定期的にバックアップする場合、データベースはバックアップ サイクルでいつでもその状態に復元できます。
1) まず、データベースを指定時刻より前のバックアップ状態に復元します。2
) バックアップ時点から復元時刻までに、バイナリ ログの内容を取得し、抽出されたバイナリ ログに従ってデータを操作して、指定された時刻に復元します。時間。
2 フェーズ コミット
1、更新 T set c=c+1 where ID=2;
1) エグゼキュータは、ID=2 が配置されているデータ ページがメモリ内にある場合、エンジンを通じて ID=2 のデータをフェッチします。そうでない場合は、返す前にディスクからメモリに読み取る必要があります。
2) エグゼキュータはエンジンから返されたデータ +1 を取得し、エンジン インターフェイスを呼び出して更新されたデータを書き込みます。
3) エンジンは新しいデータをメモリに更新し、更新操作を REDO ログに記録します。REDO ログは準備状態を処理し、実行が完了しトランザクションを送信できることを実行者に通知します。
4) エグゼキュータは binlog を生成し、binlog をディスクに書き込みます。
5) エグゼキューターはエンジンを呼び出してトランザクション インターフェイスを送信し、エンジンは REDO ログをコミット状態に変更し、更新が完了します。
2. 最後の 3 つのステップでは、REDO ログの書き込みが準備とコミットの 2 段階のコミットに分割されます。REDO ログと binlog は 2 つの独立したロジックです。2 フェーズ コミットが必要ない場合:
1) 最初に REDO ログを書き込み、次に binlog を書き込みます。REDO ログが書き込まれ、binlog が完了していないときにデータベースが異常に再起動すると仮定します。バイナリログには現在の操作が記録されず、この操作はバックアップおよびリカバリのプロセス中に失われ、リカバリされたデータは元のデータベースとは異なります。
2) 最初に binlog を書き込み、次に redo ログを書き込みます。binlog が書き込まれた後、クラッシュが発生します。REDO ログは書き込まれません。クラッシュ回復後、トランザクションは無効になりますが、binlog にはこの操作が記録されており、後続のバックアップおよびリカバリでの追加トランザクション リカバリ 出力データは元のデータベースと異なります。
3. 2 フェーズ コミットを使用すると、ログに従って復元されたライブラリの状態は元のライブラリと一致します。
4. 誤操作によるデータの復元にはバックアップとバイナリログを使用する必要があるだけでなく、バックアップ データベースを構築するために拡張が必要な場合はフル バックアップ + バイナリログが一般的な方法であり、一貫性のない操作はマスターとスレーブの間で不整合を引き起こします。データベース。
5. 週に 1 回のバックアップと比較して、最長復旧時間が短くなります。ただし、完全バックアップを頻繁に行うには、より多くのストレージ容量が必要となるため、バックアップ時間の選択はビジネス評価に基づいて決定する必要があります。
1) 最良の場合、1 日のバイナリログを使用してデータを特定の時点に復元します。2
) 最悪の場合、1 週間のバイナリログを使用してデータを特定の時点に復元します。