InnoDBストレージエンジンアーキテクチャ＆更新ステートメントは、一般的なプロセスを実行します

あなたが見ることができ、InnoDBストレージエンジンは、3つの部分に分かれています。

メモリアーキテクチャ
バックグラウンドスレッド
InnoDBストレージエンジンファイル

まず、メモリ構造

メモリ構造は、4つの部分に分かれています。

バッファー・プール
変更バッファ（バッファプールの挿入バッファ部）
アダプティブハッシュインデックス
ログバッファ（REDOログ・バッファ）

1.バッファー・プール

起動時にサイズinnodb_buffer_pool_size、によって決定されたメモリ領域に割り当てられたインデックスデータとキャッシュテーブル。専用DBサーバは、このセクションの物理メモリの80％に60％の推薦コンテンツのため。

2.変更バッファ

操作によって影響を受ける非ユニークセカンダリインデックスキャッシュDML（古いバージョンでは、したがって、挿入バッファのこの部分の前にのみキャッシュインサートを、と呼ばれることができます）。あなたがプールをバッファリングするために、ディスクから他のページの負荷データを読み込む場合は、これらのページはまた、単に変更が含まれているキャッシュされたページの変更操作をバッファリングし、記録io_ibuf_threadスレッドはバッファが変更されます実際にセカンダリインデックスにマージされます。

3.適応ハッシュインデックス

プール構造管理バッファ内部データ、および関連する操作は、ワークロードおよびメモリ・バッファ・プールは、自主規制の組み合わせです。

4.ログバッファ

保存REDOログはinnodb_log_buffer_sizeの大きさ、勧告4〜16Mによって決定されたデータメモリ領域に書き込まれます。redoログリフレッシュ周波数制御innodb_flush_log_at_timeout、ログバッファ内のログの内容を記述するかを決定パラメータinnodb_flush_log_at_trx_commit。

第二に、バックグラウンドスレッド

すべてのスレッドがperformance_schema.threadsを通じて情報を照会することができます

select name,type,thread_id,processlist_id from performance_schema.threads where type='BACKGROUND';

あなたは、MySQLのバックグラウンドスレッドに最も重要なのは、スレッド--master四つのカテゴリー、IOスレッド、パージスレッド、ページ・クリーナーのスレッドである16種の合計を見ることができます。以下は、名前と主な目的を説明します

カテゴリ	名前	使用
マスタースレッド	srv_master_thread	InnoDBストレージエンジンメインスレッド。前に5.6：データがデータファイルに書き込まれ、バッファプールは、チェックポイント、アンドゥページのクリーンアップ操作を実行します 5.6スタート：作業が大幅に軽減、主に操作を完了するために4つのサイクルを介して他のスレッドを呼び出します
IOスレッド	io_ibuf_thread	スレッドは、バッファINSERT（バッファ挿入IBUF手段）。変更バッファマージ操作を担当
	io_read_thread	IO操作スレッド読ん非同期データベース読み取り操作の責任を、。数で設定しInnodb_read_io_threads、デフォルトは4です
	io_write_thread	IO操作スレッド書くデータベースの非同期書き込み操作の責任を、。数で設定しInnodb_write_io_threads、デフォルトは4です
	io_log_thread	ログスレッドディスクにフラッシュする、REDOログ（LGWR）
パージスレッド	srv_purge_thread	元に戻すクリーンアップスレッドのクリーンアップ操作の取り消しページを担当し、。負荷を軽減するために5.6を追加した後srv_master_thread
ページクリーナースレッド	page_cleaner_thread	ダーティページのクリーンアップスレッドダーティページをフラッシュするための責任、。負荷を軽減するために5.6を追加した後srv_master_thread
他の	srv_error_monitor_thread	スレッド・エラーの監視、制御、およびエラー処理を担当します
	srv_lock_timeout_thread	スレッドロック、ロック制御とデッドロック検出の責任
	thread_timer_notifier	タイマー満了通知スレッド、一般的なSQLを自動的にmax_execution_timeにより後に終了実行します
	メイン	MySQLサービスのメインスレッドの初期化を担当する（InnoDBストレージエンジンメインスレッドとは別のノートでは）、コンフィギュレーションファイルおよびその他の機能を読み込みます
	srv_monitor_thread	印刷プロセスを監視するのInnoDBモニタがInnoDBはオンになっている場合、その情報は、すべてを収集した後、5秒を出力します、
	srv_worker_thread	InnoDBのワーカースレッド。キューからタスク実行スレッド、ポーリングの実際の作業（SELECT、INSERT）の責任者などと実行
	buf_dump_thread	プールのインポート/アウトスレッドホットプールのデータ・ページのインポート/ Aを担当し、
	dict_stats_thread	InnoDBのバックグラウンド統計スレッドのInnoDBテーブルの統計更新を担当し、
	signal_handler	信号処理スレッド、SIGTERM、SIGQUIT、SIGHUP信号処理を担当するスレッド

三、InnoDBストレージエンジンのファイル

テーブルスペースファイルとREDOログ - 実際にはデータの2つだけのカテゴリが含まれています。

表スペースに分割することができます。

表スペース
別の表スペース
通常のテーブルスペース（5.7新しいです）
アンドゥテーブルスペース
一時テーブルスペース（5.7新しいです）

1.表スペース

.ibdata *という名前のファイルには、複数のユーザーテーブルで共有することができます。デフォルトのシステムは、ibdata1とテーブルスペースという名前のファイルが作成されます、あなたは表スペースinnodb_data_file_pathの数とサイズを指定するには、システム・パラメータを使用することができます。

表スペースには、次のものがあります。

InnoDBデータディクショナリ（InnoDBは、関連するオブジェクト・メタデータ）
（PG機構は、完全なページを書き込むために使用される）、「パーシャルライト」の問題を防ぐために、バッファを二重書き込みが、ディスクバッファ上の実際の名前
アンドゥセグメント（少なくとも一つの）、オラクルを用いて

2.独立した表領域（ファイルごとの表表領域）

もしinnodb_file_per_table = 1を設定することができました。そう、彼らは統一ibdata1とファイルシステムテーブルスペースに格納されます。有効にした場合、各テーブルには、独自のインデックスとデータを格納するために使用されるの.ibdファイルを生成します。

3.通常の表スペース（一般的な表領域）

5.7の新機能は、ユーザーがInnoDBがテーブルスペース、ファイルの名前tbs_name.ibdを共有作成するために、表領域の構文を作成します。

REGULAR表スペースを追加するために、テーブルTB1 ...表領域= XXXまたはALTER TABLE TB1 ...表領域= xxxはテーブルを作成し使用することができます。

4. UNDO表領域

ファイル名アンドゥ*、同じ目的とオラクル、innodb_undo_tablespacesによって制御されるファイルの数。

InnoDBのアンドゥ合計128個のセグメント、前記セグメント32に配置一時アンドゥテーブルスペース、システム・テーブルに少なくとも1つの空間、アンドゥテーブル（95まで）に位置する残りのスペース。

各セグメント1023アンドゥトランザクションスロット、シーントランザクションに対応する各スロット並列トランザクション。つまり、一時テーブル操作32 * 1023上の並列トランザクションの最大数であり、同時トランザクションの操作の最大数は、非仮置台96 * 1023です。

5.一時表領域

innodb_temp_data_file_pathパラメータ定義ファイル名との初期サイズ、そうでない場合は、自動的に12メガバイトのibtmp1の拡張子を持つ最初のファイルを作成することをデフォルトに設定することにより、非圧縮の一時テーブルおよび関連オブジェクトのInnoDBストレージ、。

一時表スペースは、あなたが作成できない場合、MySQLは起動に失敗し、MySQLを再起動するたびに再作成されます。

information_schema.innodb_temp_table_infoテーブルに格納されたメタデータを関連する一時テーブルスペース。

6. REDOログ

オラクルとの使用は、デフォルトでは、ディスク上のib_logfile0とib_logfile1という名前のファイルを作成します。

四、更新ステートメントは、一般的なプロセスを実行します

あなたは、次のステートメントを実行していると仮定

update test set idx=2 where id=10;

でサーバーレベルのアクセス権の検証、解析、構文の検証、生成、選出された優れた実行計画。
InnoDBエンジン層に、それは、バッファー・プール内= 10データIDか否かを判定する。バッファー・プール、および関連レコードプラス排他ロックでは、データ・ファイルから読み込む必要がない場合には、その場合、読み取りステップをスキップします。
プライマリ・キー値と対応するプリ変性IDX、トランザクションID情報ロールバックUNDO表書き込まれます。
バッファプールに対応するデータ・ページを変更し、更新レコードとログバッファにLSN新しく生成された値を書き込み、バッファプールの汚れのページで更新されたページになります。
トランザクションがコミットされると、最初のデータもバイナリログファイルの名前と場所の後に書き込みREDOログをリフレッシュREDOログをバッファリングし、その後書き込みビンログ、バイナリログ（ディスクへの同期）に提出され、バイナリログの同期更新にログインします。そして、それは本当にトランザクションの提出を完了した場合には、REDOログにコミットマークを書き込みます。排他ロックの解除後に提出しました。
あなたは二重書き込みバッファ機能を書くことになる場合は、データが時間外でバッファリングした後、バッファプールからのダーティー・ページは、データ・ファイルを更新するには二重書き込み時に、二重書き込みバッファをリフレッシュするダーティページ、オンになっています。それは、直接データファイルを更新するには、バッファプールからのダーティ・ページを選択するには、バックグラウンドスレッドから、オンにされていない場合。

五、MySQLのフォアグラウンドスレッド

フォアグラウンドスレッド缶クエリもperformance_schema.threadsすることができ

select name,type,thread_id,processlist_id from performance_schema.threads where type='FOREGROUND';

5つの主要なフォアグラウンドスレッド、次のように主な機能があります。

名前	使用
compress_gtid_table	GTID圧縮スレッド。圧縮GTID新しいテーブルを記録するための5.7 mysql.gtid_executed
one_connection	ユーザーの接続スレッドユーザー要求を処理するための
slave_io	IOスレッドは、メインライブラリのbinlogを引っ張っする責任があります
slave_sql	SQLスレッド、責任シングルスレッドのレプリケーションは、メインライブラリのbinlogを適用します。マルチスレッドレプリケーションで、コーディネータのbinlogスレッドとしてslave_sqlがslave_workerスレッドが実際に適用され配布されます、そしてそれは、複数のslave_workerの調整のために責任があることに注意してください
slave_worker	ワーカースレッド。マルチスレッドの複製は、複製のbinlogスレッドは、実際にslave_sql分布を適用します