簡単に言えばMySQLサーバは、層とストレージエンジン層に分かれています。
サーバ層：例えば、ストアドプロシージャ、トリガ、ビュー、関数、等のすべてのストレージエンジンの機能をこの層に実現される両端のコネクタ、クエリキャッシュ、アナライザ、オプティマイザ、アクチュエータ等を含む、一般的には、ありますログモジュールbinglogログモジュール。
ストレージエンジン：データ保存と検索のための主な原因とは、InnoDBは、MyISAMテーブル、メモリ、およびその他のストレージエンジン、モジュールredoログモジュール独自のログを持っているInnoDBエンジンをサポートプラグインアーキテクチャの使用を置き換えることができます。
今、最も一般的に使用されるストレージエンジンInnoDBは、それが最初からのMySQL 5.5.5バージョンのデフォルトのストレージエンジンとして扱われます。
ベース層を導入.Server
1）コネクタ
高いガードのと同じレベルのようなメインコネクタと認証、および権利関連機能、。
ユーザーアカウントのパスワードが経過した場合などのオペレーティングチェック・アカウント・パスワードを含むデータベースのユーザログイン、ユーザ認証、権限、責任、コネクタは、すべての権利権限テーブルのクエリにユーザーを移動しますが、
これに関連して、権限の論理判断した後、この時点である長期フォローアップ接続がすぐにではないとして、管理者がユーザーの権限を変更して、ユーザーにも影響を受けず、あること、データを読み取るためのアクセス許可に依存します。
2）クエリキャッシュ（削除のMySQL 8.0バージョン）した後、
メインクエリキャッシュは、私たちが実行され、結果はステートメントを設定し、SELECTステートメントをキャッシュするために使用しました。
接続が確立された後、時間は、クエリを実行するために最初のクエリキャッシュ、MySQLは最初にこのSQLを実行するかどうかをチェックしますので、メモリ内のキーと値の形でキャッシュ、キーが期待されているクエリは、値は、結果セットがあります。
キャッシュキーがヒットした場合の結果の完了がキャッシュされます後、それは、フォローアップ操作を実行する、ヒットしない場合は、直接クライアントに便利な次の呼び出しが返されます。もちろん、あなたが実際にクエリキャッシュを実行すると、クエリのテーブルがある場合は、まだ、ユーザーの許可をチェックします。
実際のビジネスシナリオでのクエリキャッシュの無効化を使用すると、テーブルを更新する場合は、このすべてのキャッシュが空になるテーブルのクエリになり、非常に頻繁にすることができので、MySQLのクエリキャッシュは、推奨されません。頻繁に更新されていないデータの場合、キャッシュの使用は可能です。
だから、一般的には、ほとんどの場合、我々は、クエリキャッシュを使用することを推奨されていません。
MySQLの8.0バージョンは、キャッシュ機能を取り除いた後、正式にはこれだけ直接削除、実用的なアプリケーションシナリオではあまり機能と考えられています。
3）アナライザ
MySQLはそれがアナライザに入り、キャッシュにヒットしませんでした、アナライザは主にここでやっているSQL文を分析するために使用され、アナライザはステップに分割されます。
最初のステップ、字句解析は、SQL文は、最初に、このような選択、昇給クエリ、フィールド名が前方提案置くクエリなどなどのキーワードを、抽出する必要があり、複数の文字列を持っています。そして、その操作の後、彼らは第二段階に入ります。
入力した第二段階、構文解析、主にSQL裁判官は、MySQLの構文かどうか、正しいです。
これらの2つのステップを完了した後、MySQLは、しかし、実行する方法を、どのように最良の結果を実行するために開始する準備ができているのですか？今回は、オプティマイザを再生する必要があります。
4）オプティマイザ
オプティマイザの役割、それが実行するプログラムの最適な実装と考えていることである（そして時には最善ではないかもしれないが、この記事では説明のこの部分の深い知識を必要とする）、このようなインデックスの時間を選択する方法として、複数のインデックス、マルチテーブルどの順番などに関連するクエリの時間を選択します。
オプティマイザはこの文が落ち着くする方法を具体的に実行されたことを言うことができた後は、言うことができます。
5）アクチュエータ
あなたがプログラムの実施を選択すると、MySQLは開始する準備ができて、そして最初の実行は、ユーザが何の権利を持っていないことを確認します前に許可を持っていない場合、それは、エラーメッセージを返します、あなたが権限を持っている場合、エンジンインタフェース、インタフェースのリターンを呼び出すことになります実行結果。
二つの文の分析
2.1クエリ
そんなに言って、そのSQL文は、それを実装する方法は何ですか？実際には、私たちのSQLには二つのタイプに分けることができ、一つは1は（追加、更新、削除）、更新クエリされています。次のように私たちは、最初次のクエリ文を分析し、文は次のとおりです。
選択 * から tb_studentのA A.age = ' 18 ' と A.name = ' 张三'。
上記の説明に関連して、我々はこの文の実行の流れを分析します：
1.クエリ結果がある場合、文は権限を持っているかどうかをまずチェックは、無権限場合は、権限を持っている場合は、直接、エラーメッセージを返し、MySQL8.0以前のバージョンでは、このSQL文になります最初のクエリキャッシュは、メモリ内のキーでありますそこに直接キャッシュであり、そうでない場合、次のステップ場合。
2.このような選択、抽出tb_studentテーブル名上記のクエリ文を抽出するなどのSQLステートメントのキー要素を、抽出分析を介して字句解析は、照会する、すべての列を照会する必要性は、このクエリは、1」=テーブルIDであります」。
そして、チェックが次のステップに問題はありません場合は、SQL文は、このように正しいキーワードなどかのように、構文エラーがあるかどうかを判断します。
3.次のステップは、プログラムの2つの実装が存在するプログラム、上記SQL文のオプティマイザ決定実装です。
。学生は「ジョン・ドウ、」学生として最初のクエリのテーブル名、そして年齢が18であるかどうかを判断します。
B。まず、学生の年齢18歳の学生、「ジョン・ドウ」の生徒として、クエリの名前を見つけます。
4.オプティマイザは、（必ずしも最善時々 、思うオプティマイザ）、独自の最適化アルゴリズムに従ってプログラムの最高の実行効率を選択します。だから、実行を確認した後に実装する準備ができて計画しています。
5.権限がある権限は、データベースエンジンインタフェース呼び出された場合、エラーメッセージを返します許可なしに、チェックし、結果がエンジンを返しました。
2.2更新ステートメント
上記は、SQLクエリの実行プロセスであり、その後、次の我々は、更新ステートメントが、それをどのように実行されるかを見てみましょうか？次のようにSQL文は次のとおりです。
更新 tb_student Aは設定 A.ageを= ' 19 ' ここ A.name = ' 张三'。
年齢でジョー・スミスへレッツ・変更は確かに、データベース内のフィールドの実際の年齢を設定していない、または遊びのテクニカルディレクターであることを。
実際には、この文は、プロセスがクエリに一緒に行くだろう、唯一の時間は確かにそれをログに記録更新を実行する必要があります基本的に、それは、モジュールの導入を記録します
MySQLは、ログモジュラーbinlogの（アーカイブログ）が付属して、すべてのストレージエンジンを使用することができ、我々は、InnoDBエンジンを使用また、ログモジュールのREDOログ（REDOログ）が付属しています
私たちは、実装プロセスのInnoDBダウンモードにこの文を議論する必要があります。次のようにプロセスは以下のとおりです。
- キャッシュがある場合にジョー・スミスが最初のチェックには、このデータは、キャッシュにも使用されます。
- その後、クエリステートメントを取得し、年齢が19に変更し、その後、エンジンのAPIインターフェイスを呼び出して、データのこのラインは、この時点では、メモリに保存されているInnoDBエンジンのデータも記録REDOログ、REDOログを書かされた状態に入るための準備、そして通知、提出する準備ができて、完全に実行します。
- アクチュエータ、通知レコードのbinlogを受け、そして後に、エンジン・インターフェースを呼び出す状態の提出のためにREDOログを提出します。
- アップデートは完了です。
使用2つのログモジュールは、ログモジュールを使用していない理由はここに学生は確かに、聞いてきますか？
ほとんどが（プラグインを挿入し、他の企業へのInnoDBエンジンでのMySQL）InnoDBエンジンでのMySQLを起動していなかったためであり、
MySQLの独自のエンジンはMyISAMのですが、私たちは、InnoDBエンジンをREDOログ・知っていることは、例外を再起動するために、データベースの能力が発生した場合に提出する前に、クラッシュセーフ機能（クラッシュセーフさえにつながることはありません他のストレージエンジン、ユニークではありませんレコードが）失われていない、バイナリログログはアーカイブのためだけに使用することができます。
唯一のログモジュールだけではなく、InnoDBエンジンがREDOログをサポート取引ことができることを言うまでもありません。
、その後、学生が尋ねる何があるでしょう、私は2つのモジュールを記録するために使用されるが、その前の提出状況の導入を準備する大丈夫、なぜREDOログを複雑になることはありませんか？ここでは、次の操作を行うために理由を説明する背理法を使うのか？
- 最初は、ログをやり直すために直接書き込むために、書き込みのbinlogは、REDOログの後に終了したと仮定して、マシンがハングアップし、binlogのログが書かれていませんし、マシンを再起動した後、マシンは、REDOを介してデータログを復元しますが、今回はbingogませんでしたこれは、データの失われた部分であるとき、後続のバックアップマシンのデータを、記録したデータが失われ、マスタ・スレーブ同期中。
- binlogの書き込みには、書き込みREDOログは、終了しているバイナリログを想定し、マシンをリブートは、無REDOログので、マシンはこのレコードを回復することができないが、そこbinlogの記録、および上記同じ理由、それは持っていますデータの不整合。
REDOログ2フェーズ・コミット方法が同じでない場合は、binglogを終えた後、REDOログを送信する前にこのようにデータの一貫性を確保し、上記の問題を防ぐことができます。
そこで質問があり、極端な状況はありますか？前のコミット状態のREDOログを想定し、binglogは何が起こるときに異常再起動この問題が発生し、終了していますか？これは次のようにMySQLのの処理機構に依存し、MySQLのプロセスは次のとおりです。
- 裁判官のREDOログは、判断が完了した場合には、直ちに提出し、完了です。
- REDOログは事前に提出したが、状態をコミットしていない場合は、裁判官へのこの時間は、あなたが完全なREDOログを提出する場合は、トランザクションをロールバックすることは完了していない、完全なバイナリログであるだろう。
これは、データの一貫性の問題を解決するだろう。
IIIまとめたもので
- MySQLサーバは、redoログ、層は、主コネクタサーバー、クエリキャッシュ、アナライザ、オプティマイザ、エグゼキュータ、ならびにログモジュール（バイナリログ）を含む、ログモジュールは、すべての実行エンジンを共有することができ、層およびエンジン層に分割されています唯一のInnoDBはあります。
- エンジン層は、プラグイン今のMyISAM、InnoDBは、メモリなど、を含む、です。
- 次のようにクエリの実行プロセスは、次のとおりです。パーミッションのチェック（キャッシュヒットの場合）---「クエリキャッシュ---」---アナライザ「オプティマイザ---」権限のチェック---「アクチュエータ---」エンジン
- UPDATE文の実行プロセスは、次のされています。アナライザは----アクチュエータ--- --- binlogの「REDOログ（コミット状態「エンジン--- REDOログは、（状況を---準備」「----権限チェック」 ）