私たちは、SQLクエリの実行と語っ前の記事。以前の記事を読んでいない場合は、我々は、SQL更新を実行したプロセスについて話今日、記事を見ることができます。
更新スコア設定 スコア= C +10 ID = 1
SQL IDは、1〜10のプラスの割合を超えています。
そして、その実行の流れはそれが何ですか？以下のように、マップの記事に借入：
私は、MySQLサーバは、接続後に実行されたSQL文は、実装プロセスのSQLパーサを通過する必要が、更新操作を行う必要がある来る接続するための最初のすべてのクライアントの、この再単純なプロセスについて話をするためにここにいます、オプティマイザによって、その後は、それを使用することを決定しました行、最後の更新操作を見つけるIDインデックスと、インデックスを介してアクチュエータを通ります。
これらはあまりにも全体のプロセス操作を通じて更新されます。あなたは完成していたと思うだろうと言ったが、私はそれはまだ始まったばかりだあなたを伝えるために後悔しました。
更新およびクエリ操作は同じではありませんので、更新操作は、2つの非常に重要なログモジュールを必要とします。ログ（REDOログ）とビンログ（アーカイブログ）をやり直します。二人は今日は焦点であると言います。
まず、これらの2件のログが何であるかを知っている必要がありますか？そして、あなたは彼らがやっていることを知っている必要がありますか？
REDOログInnoDBエンジンは、「データ・ページに行われた変更」それは主に、記録のために、物理ログに属し、独特であり、その記録容量は固定されて実行されます。
ビンログはそうmysqlのすべてのエンジンは、それを使用することができ、サーバー層の保有、主に再アクチュエータロギングを属します。ビンログは、それが、論理ログを所属 の文 と行 のモード、二つのレコード、一つのコンテンツを更新する前に、追加的であるように、内容を記録した行の行を更新文が実行されたSQL文に記録されていますアップデート後。デフォルトのモードは、モード行です。さらにビンログがログに書き込ま追加されて、ログファイルを特定のサイズに書かれていると、彼らはログを書き続け次に切り替わり、以前のログファイルを上書きしません。
これらは、概念とこれらの2つのログの役割なので、今は自分の記録プロセスについて話をする必要があります。以下の下の画像を見てみましょう、アクチュエータの動作のための黄色の色を塗りつぶし、青のエンジン運転のInnoDBへの塗りつぶしの色
少し長い図が、理解しやすいはずです。そして、今段階の分析によってステップ。
図1に示すように、第一のアクチュエータは、このデータID = 1を見つけるためにエンジンがかかります。
idが主キーであるため、2、ので、データの行を見つけるためにツリーを使用。しかし、エンジンは、メモリページのデータがあるかどうかを見つけるために行きます。
図3に示すように、データがアクチュエータに直接返された場合、それがメモリに読み込まれ、ディスクのデータに移動し、アクチュエータにデータを返すわけではない場合。
図4に示すように、アクチュエータは、操作C + 10を実行します。
図5に示すように、アクチュエータは、データの新しい行を生成します。
図6は、メモリへの書き込みポートのInnoDBエンジン、更新されたデータを呼び出します。
7、InnoDBエンジンは、REDOログログマークの状態は準備書かれた、およびアクチュエータデータは、トランザクションがいつでも提出することができる完成された更新された言われます。
図8に示すように、このビン・ログ、およびビンログの書き込み操作がディスクに書き込まれているアクチュエータと
図9は、最後の実行エンジンは、これまで全体の更新操作が完了すると、REDOログコミットの状態を変更するには、トランザクション・インタフェース・エンジンをコミットするために呼び出します。
たぶん、あなたはいくつかの質問に出てくるここを参照してください？
1は、スペースが固定されているREDOログ、それはそれが不足していないのだろうか？
まず、それはリサイクル可能ですので、スペースの不足になりますREDOログを心配しないでください。例えば4つのファイルは、それぞれの組のそれぞれ1Gとして構成ログREDOログ。以下に示すように、それが流れて書きます：
REDOログの現在位置消去さを示す2つの塗りつぶしの色、黄色及び赤色、黄色でマークされたチェックポイント、上図は、赤は、REDOログ内の現在のレコードの位置を示すPOSを、書き込みマーク。REDOログがいっぱいになると、それはそれは、ディスク、データの永続性にデータを書き込みますログを消去する前に、当然のことながら、REDOログ・操作を消去し、データが書き込まれていない、停止します。データの正確性を保つように。
2、なぜこの二つは、それを記録する必要がありますか？InnoDBエンジンが存在しない場合に何のREDOログ・ログではありませんので。
InnoDBのエンジンは、データベースがダウン突然または異常な再起動の場合でも保証できるので、REDOログ、以前に提出されたデータは失われません。クラッシュセーフこの能力を呼びましょう。
3は、実行中のMySQLサーバーが突然ダウンしたときに、データが失われることはありませんか？
答えはノーです。なぜそうしてください？我々は2つ目のグラフから見ることができます。たとえば、次のような状況：
1、トランザクションが提出されていないため、変更は、REDOログを書き込まれる前に、元のデータが送信されていない、ダウンしています。
2. IFが、書き込みREDOログの後、ビンログをダウン書き込む前に、元のデータがまだデータベースが再起動されているため、両方のログの記録が同期していないので、変更されませんので、新たに生じたデータはないが存在します。
3、REDOログは、データが更新されたデータになった後、この時のREDOログとビンログレコードを持っているので、再起動されたデータベースは自分自身をコミット行いますので、データベースを再起動して、ダウンしているコミット生成されたので、この時間を前に、データは、データを更新しています。
私たちは、主にこのパラメータを1に設定されている、それはそれぞれが直接ディスクに永続トランザクションをREDOログ表しinnodb_flush_log_at_trx_commit、そのクラッシュセーフ機能を確保するために必要なREDOログを使用します。私は、これは、データが異常な再起動のMySQLの後に失われないことを確実にする1にこのパラメータを設定示唆しています。
このパラメータが1に設定されているsync_binlog、各トランザクションは、バイナリログを表し、ディスクに永続化しています。私はまた、このパラメータが1に設定されているあなたを示唆ので、あなたは、MySQLバイナリログが異常再起動後に失われないことを確認することができます。
さて、今日は、間違った場所が議論我々が一緒に学ぶことを指摘して歓迎の書き込みにあれば、と述べました。