まず、ストレージエンジン
1、InnoDBエンジン
アプリケーションは、オンライン・トランザクション（OLTP）プロセスのために設計されています。
トランザクション、行レベルのロック、マルチバージョン同時実行制御（MVCC）から高い並行性のサポートは、一貫性のある非ロックリード、ファントムリードを回避するために、次のキーロック、主キークラスタ化インデックスを提供するサポート
2、のMyISAMエンジン
これは、OLAPアプリケーション用に設計されています。
行ロックをサポートしていないトランザクションをサポートしていない、テーブルロックは、フルテキストインデックスをサポートするように設計します
3、他のストレージエンジン
わずかに
二、InnoDBのアーキテクチャ
1、スレッドモデル
InnoDBストレージエンジンは、異なるタスクを処理する異なるスレッドの数が存在するマルチスレッドモデル、バックグラウンドです。
- マスタースレッド：ディスクにフラッシュカーネルスレッド、非同期データバッファプール
- IOスレッド：コールバック要求を処理するためのIO責任
- パージスレッド：責任アンドゥページをリサイクル
- ダーティページの責任リフレッシュ：ページクリーナースレッド
1.1、マスタースレッド
内部構成要素の複数のサイクル。メインループ（ループ）を含む、バックグラウンド・ループ（バックグラウンド・ループ）
毎秒メインループ動作
- ログバッファは、トランザクションがまだコミットされていない場合でも、ディスクにフラッシュされます。まあ説明した後、大きなトランザクションがコミット時間が非常に短く、
- 合わせ挿入バッファ
- （設定、自動調整の後、バージョン1.2）ディスクへのn番目のリフレッシュダーティページまで
- いいえユーザアクティビティ、バックグラウンドループに切り替えていません
メインループ10秒ごとの操作
- 合わせ挿入バッファ最大5
- ログバッファをディスクにフラッシュされます
- 不要なページを削除元に戻します
- ダーティー・ページをディスクにフラッシュする（70％以上、100、70％以下、10をリフレッシュします）
2、メモリモデル
2.1、バッファ・プール
バッファプール読み取りからInnoDBがメモリに格納されているディスクから読み出されたギャップCPUとディスクのパフォーマンスおよびデータを橋渡しするために、ディスクベースのストレージシステムであり、次は最初に読み取ります。Esen更新データをディスクに書き戻し、チェックポイントメカニズムによってデータ・バッファ・プールを更新します。プール索引ページを含む、データページは、ページを元に戻すには、キャッシュ、ロック情報を挿入し使用し、
2.2、バッファプール管理（LRUリスト）
最近のアルゴリズム、リストのフロントページのリストの最後に使用以上の中で最も頻繁に使用されるページの少ない利用しました。プールの容量が不足している場合、データ・ページの尾のリリース以降、新しいデータを収容します。新しいデータが中点の一覧に挿入されている（5/8の一覧、最適化の単純なLRUは、LRUは、単純な挿入ヘッド一覧。頻繁に使用されるクエリ使い捨てブラシバッファー・プールのページの多数を避けます）
2.3、ダーティ・ページ管理（フラッシュ一覧）
データが更新されると、第1のデータバッファプールが汚いページとして知られている変更後、ページを更新しました。ダーティページは、チェックポイントのメカニズムによってリストをフラッシュするために、ディスクに書き込まれたデータのダーティページを保存しました
2.4、（REDOログ）バッファREDOログ
まず、情報は、REDOログ・バッファに格納され、その後、REDOログ・ファイルに同期特定の周波数に追従します。次の3つの場合は、REDOログ・ファイルに同期REDOログバッファをトリガします。
- マスタースレッドは毎秒リフレッシュ
- 各トランザクションは、コミット時
- バッファプールの容量は、典型的には、閾値に達したREDOログ1/2
2.5ポイントの技術をチェック
コミットされていないトランザクション情報が得られ、ダウンタイムを防ぐために、トランザクションがコミットされたときに、失われた最初のREDOログにデータを保存（REDOログ）、その後、ページを変更しています。（D）の耐久性を確保するため
ダウンタイムの発生、データを回復するためにREDOログ後の自動再起動。
しかし、次のような問題があります。
- あまりにも、ログが大きすぎるやり直し、再起動回復データを遅く
- REDOログが無制限に拡張することはできません、私たちは、リサイクルする必要があります
- REDOログが行う方法は使用できません
チェック・ポイントは、これらの問題を解決することです。
- データベース短く回復時間
- ログが使用できないやり直し、汚れたページを更新
- バッファー・プールは十分に、ダーティページがディスクにフラッシュされているではありません
ポイント・トリガのタイミングを確認してください。
- マスタースレッドのチェックポイント。1秒ごとにトリガ
- LRUリストのチェックポイント。LRUリスト100の空きページがあることを確認するために、ページがあればダーティページをクリーンアップする必要があり、トリガーチェック・ポイントは、リフレッシュにディスクへのダーティ・ページを強制的に
- ダーティページあまりにもドロドロのチェックポイント。あまりにも多くの汚れたページのしきい値は、ディスクにリフレッシュダーティ・ページを強制するために、トリガチェックポイントを超えています
3.主な特徴
3.1、キャッシュを挿入
キャッシュを挿入する（1）なぜ必要？
私たちは、インデックスがクラスタ化インデックスと非クラスタ化インデックスに分かれていることを知っています。
一般的には、書き込みデータが別のランダムリードのページを必要としませんが、ページを保存するために、インデックスインクリメント、データレコードをクラスタ化された固有のID、高速書き込み（UUID場合、主キー、書き込み速度など非常に遅い、各書き換えは、ランダム読み取りが必要です）
実用的なアプリケーションでは、非クラスタ化インデックスのテーブルが存在していることが多いです。非クラスタ化インデックスのリーフ・ノードは、データのランダム挿入は、パフォーマンスの低下につながっ読み、離散非クラスタ化インデックスページにアクセスする必要がないために挿入されています。キャッシュの挿入は、このシナリオで挿入速度を最適化することです
（2）シーンが挿入キャッシュをトリガしますか？
- インデックスがセカンダリインデックスであります
- インデックスは、一意のインデックスではありません
次いで、挿入バッファ・オブジェクトに直接インデックスページへのバッファ・プール、そうでない場合は最初に、特定の周波数場合、非クラスタ化インデックスの挿入のために、まず、バッファプール内の非クラスタ化するかどうかをインデックスページを決定しますリーフノードの挿入バッファデータと非クラスタ化インデックスのデータ統合
（3）原則
記録時間を挿入するために、また、B +ツリーであり、記録は、パッケージ化された記録の挿入順に従って番号付けされ、書き込み順は、バッファデータ構造を挿入
3.2、二回の書き込み
2件の書き込みを挿入する（1）なぜ必要？
ページのInnoDBデータがディスクに書き込まれている場合は、単に時間の部分を書き留めます。この条件は、データの損失につながる部分書き込み失敗と呼ばれています
（2）原則
二重の書き込みは、2つの部分から構成されています。二重書き込みバッファの一部、物理ディスクの一部を連続的に空間を共有しています。データのダーティページをフラッシュすると、二回書き込みキャッシュへのダーティページデータのコピーを作成し、（それが書かれているので、順序のパフォーマンスに影響を与えない）シーケンス共有ディスクに書き込みます。最後に、データ記憶ディスク（離散書き込み）を書き込みます
3.3、適応ハッシュインデックスの最適化
ハッシュは、非常に高速なクエリ時間はO（1）の度合いを担当しています。回数はBを見つけるために+ツリーは、ツリーの高さに依存します。
ページには、頻繁にアクセスするだけでなく、（原則左端の共同インデックスを使用して）同じアクセスモードされている場合。自動的にインデックスバッファプールに基づいてハッシュインデックスを確立するためのデータこのページの検索をスピードアップします
3.4、非同期IO
、IO要求、他によって発行されたIO要求を発行した後、IO要求処理に次のを待つ必要が完了していない可能性があります。すべてのIO要求がAIO（Aysnc IO）で、すべてのIO操作の完了を待っ、送信されます置きます
第三に、ファイル
MySQLデータベースとInnoDBストレージエンジンは、それぞれが異なる目的をファイル、ファイルの多くの種類があります。パラメータファイル、sokcetファイル、PIDファイル、ログファイル、ファイルのテーブル構造、ファイルストレージエンジンがあります。
1、ログファイル
- エラーログ：エラーメッセージを起動し、実行記録と接近遭遇
- クエリログ：クエリのすべてのレコードの記録
- バイナリファイル（バイナリログ）：すべてのデータ変更を記録します。データ復旧とデータ複製のために。バイナリログコミットされていないトランザクションがバッファに格納され、バッファは直接、トランザクションのコミット時のように、バイナリログファイルに同期されます。ライト・バッファをディスクに何回構成の同期によって指定することができた後に値が1より大きい場合、ダウンタイムが発生したときにデータが失われる可能性があり
- スロークエリログ：指定されたしきい値以上のクエリ時間記録
2、InnoDBストレージエンジンファイル
- 表スペースのファイル：データストレージ
- ストアのトランザクションログ：REDOログ・ファイル
第四に、テーブル
1、索引構成表
InnoDBは、テーブルのデータはプライマリ・キーに格納された順番に従って編成されます。主キーの定義は、示されていない場合は各テーブルには主キーとして、意志一意のインデックスを主キーを持っています。一意のインデックスは、主キーとして自動的に6バイトのポインタを作成していない場合
図2に示すように、ストレージ構造
すべてのデータは、セグメント、領域、ページ構成によって表スペース、および表スペースに格納されます。
- グループ：各セグメントによって定義された表スペース。管理セグメントは、エンジン自体によって行われます
- 地区：1Mの各地区の大きさ、連続ページから成ります
- ページ：ディスク管理の最小単位、16Kそれぞれのデフォルトのページサイズ
- ライン：データが格納されているページまで、列に格納された16K / 2-200 = 7992行
V.インデックス