MySQLのデフォルトのストレージエンジンは「storage_engine」LIKEコマンドSHOW変数を使用して、InnoDBのです;
、InnoDBストレージエンジンの
トランザクショナルデータベースエンジン用1.InnoDBの選択、トランザクションセーフテーブル（ACID）のサポート
（MyISAMテーブル：トランザクションがサポートされていません。のみサポートテーブル・レベルのロッキング）
トランザクションのACID特性：すなわち原子性、一貫性、分離性、耐久性
アトミック：アトミックステートメントのセットが実行されたすべてのまたはすべての実行されないいずれかのことを、トランザクションが半分エラーに実行された場合、データベースは、ローカル事務の実施の先頭にロールバックする必要があります。
実装：主にベースのREDO MySQシステムログとはメカニズムを元に戻します。トランザクションは、SQL文のセットで、選択、クエリは、ある機能を削除します。各ステートメントは、ノードが存在します。たとえば、delete文が実行され、トランザクションに保存レコードがある、我々は何かを行っているレコード店。エラーが発生した場合、それは元の位置にロールバックされます、私は何かをしたし、それを逆にそれを再度実行して内部で、やり直しが格納されています。
Bの一貫性：開始とトランザクションの終わりには、データベースの整合性制約は、前に破損していません。：（例えば、Bの転送のために、お金がAバックルすることができないよう、Bは受け取っていない）
;.異なるトランザクション間で互いに干渉することなく、同じ時間、同じデータのためにのみ1つのトランザクション要求：C分離の
ない場合アイソレーションは、いくつかの疑問が生じ検討します。
私は、ダーティリードは：コミットされていない別のトランザクションを（読み込まれたデータでトランザクション処理を参照するトランザクションは、データが複数回変更されているが、このトランザクションでは、この多くの時間はまだ変更していないとき（ダーティが別のコミットされていないトランザクションを読み取る）;）、取引データへの同時アクセスの場合を提出する、取引は、2つの得られたデータの不整合をもたらす
ためのデータベースで：II、非反復可能読み取り（クエリを提出し、以前のトランザクションデータを読み出すが同じであり、データは、トランザクションの範囲内で複数のクエリは、クエリの間隔によるものであり、送信別のトランザクションによって変更され、異なるデータ値を返しましたデータ項目）
III、ファントム読み取り：から作られたすべての行のテーブル内のデータ項目にトランザクションT1「1」〜「2」の動作：ときに、非独立のトランザクション実行（EG生じる現象であります、トランザクションT2と時刻T1は、ユーザが、我々は単にデータ表の行は、データ項目の値ながら又は「1」に、データ項目に挿入され、データベースに送信された変更かどうかを確認するためにトランザクションを操作 （全体としてのデータのバッチを提出し、以前の取引データを読み込み）;私たちは、線）のように、幻覚のように、このラインは、トランザクションT2から追加され、実際には、変更しないでそこにあることがわかった
トランザクションが完了した後に永続D :. 、データベーストランザクションに対するすべての更新はデータベースに保存されます、あなたがロールバックすることはできません
2.InnoDB MySQLはデフォルトのストレージエンジンです（デフォルトでは分離レベルRRあり、そして一歩近づいRR分離レベルでは、マルチバージョン同時実行制御によるファントム読み取りの問題を解決するために（つまり、同時実行制御である）非反復可能読み取りの問題、プラスクリアランスロックを解決するためのMVCC）。優れた同時パフォーマンスを維持しつつ、InnoDBののRR分離レベルは、実際には、効果のシリアル化のレベルを達成します。
4つの隔離MySQLデータベースは、のレベルを提供してくれます。
、直列化（シリアライズ）：ダーティリード防ぐことができ、反復不能読み取り、ファントム読み取りが起こり、（、シリアライズ、クエリの効率に大きな影響を使用していない）
B、反復可能読み取り（反復可能読み取り）：CANダーティを読み出し避ける、非反復発生読み出す;（デフォルトの分離レベル）
C、コミットリード（コミット読み取り）：ダーティが発生読み出し回避でき;
D、リードがコミットされていない（非コミット読み取り）：最低レベルは、いずれの場合にもすることができません保証され;
A ---- D分離レベルからハイからローに、より高いレベル、より低い効率
3.InnoDBは行レベルのロックをサポートします。行レベルのロックが同時最大をサポートすることができ、行レベルのロックは、ストレージエンジン層によって実現されます。
主な役割は、トランザクション分離実現するために、共有リソースへの同時アクセスを管理することであるロック：ロック
共有ロック（ロックを読んで）、排他ロック（書き込みロック）：タイプを
MySQLのロックの取り組み：テーブルレベルロック（小さなオーバーヘッド、同時実行）低い、通常サーバ層に実装
行レベルロック（大きな出費、高い並行性）、ストレージエンジンレベルで実装される
4、InnoDBの最大性能のために設計された大量のデータを処理するように設計されています。そのCPUの効率は、任意のディスクベースのリレーショナルデータベースエンジンが一致しないことができてもよい
5は、InnoDBストレージエンジンは完全にメインメモリにキャッシュデータとインデックスにMySQLサーバ、InnoDBストレージエンジンと統合され、それ自身のバッファプールを維持します。InnoDBテーブルとインデックスを論理表スペースで、表スペースファイル（ディスクファイルまたは元の）の数を含むことができる;
。、それぞれ表6、InnoDBのサポート、外部キーの整合性制約、テーブルに格納されたデータの中に格納されています主キーが指定されたときにテーブル定義が表示されていない場合は、主キーを格納することは、順序に従っています。InnoDBは行ごとに6バイトのROWIDを生成し、主キーとして
7は、InnoDBのは、多くの高パフォーマンスで使用されている大規模なデータベースサイト要求され
た行8の数、InnoDBのないストレージテーブル（例：SELECT COUNT（*）からのタイムテーブルを、InnoDBは再び行の数を計算するために、テーブル全体をスキャンする必要があります）。 ;テーブル全体を空に、InnoDBが行で行を削除することで、効率が非常に遅い
（のMyISAMエンジンは、テーブルの行数を記録します）
InnoDBはInnoDBのを使用し、ディレクトリを作成していない、MySQLはMySQLデータディレクトリ内ibdata1と呼ばれるファイルを作成します。サイズ10メガバイト自動データファイルの拡張子、および5メガバイトログのサイズとib_logfile1 ib_logfile0という名前の2つのファイル
2つの基礎となるエンジンはInnoDB達成するために、
それぞれInnoDBが2つのストレージファイルを持っている、と接尾辞の.frm .idb、前記の.frmテーブル定義ファイルは、データファイルのテーブル.idbです。
1、InnoDBエンジンは、構造としてB +ツリーインデックス構造を使用して
Bツリー（バランス探索木多重）：平衡探索木は、のために設計されたディスクストレージデバイスがロードされ
たシステムデータディスクブロックにディスクメモリから読み出されますビットの基本単位は、一つのディスク上のデータブロックは、オンデマンドで読み取るのではなく、一度だけ読み出されます。
データ・ページの読み取りとInnoDBストレージエンジンを使用すると、ページがそのディスク管理の最小単位である、デフォルト・ページ・サイズが16K。
ディスクブロックシステムのストレージスペースは、多くの場合、それほど大きくないが、InnoDBはこのように、各アプリケーションは、ディスクスペースの数になります16キロバイトのページの大きさに到達するために連続したディスクブロックに取り組みます。
ページがディスクI / Oを削減するであろう、記録されたデータの位置を特定するために助けることができる場合は、ディスクの数は、ディスクにデータを読み込み、InnoDBは、あなたがデータを照会ページの基本単位、各データとなり、クエリの効率を向上させます。
Bツリーデータ構造は、システムが効率的にデータブロックのディスクを検索することができ
各Node B-Treeが、実際の実施形態によれば、キー情報及び枝、かなりの量が含まれる場合があります。
ディスクブロックが占有するディスクスペースの各ノードは、キーワードの昇順に二つのポインタと、ルートノードの子ノード上の3点があり、アドレスポインタは子ノードが配置されているディスクブロックに格納されます。
ルートで、例えば、17キーワード35、17未満のデータ範囲P1サブツリーポインタ、データ範囲P2サブツリーポインタ17 ---- 35、データポインタP3サブツリー35より大きな範囲、
シミュレーションキーワード検索手順29：
ルートディスク1を見つけることによるブロックは、メモリに読み込まれます。[ディスクI / O操作が初めて]
Bは、ディスク・ブロック・ポインタP2を見つけるために、セクション29（17、35）のキーワードを比較する。1 ;.
。実測値Cのディスクブロック3は、ポインタP2のようにメモリに読み込まれます。[ディスクI / O操作は、第】
ディスクブロックポインタP2を見つけるために、間隔（26、30）29個の比較キーワードをDは3 ;.
E 8つのP2は、メモリに読み込まれ、ディスクブロックのポインタを見つけます。[ディスクI / O操作は、第三]
F。8ディスクブロックのキーワードリストで29検索キーワード
MySQLのInnoDBストレージエンジンは、永続的なメモリをrootに設計されており、したがって、ツリーの深さを達成するために努力されつまり、3以下で、I / Oは、以上の3倍を必要としません。
上記の分析結果は、それが必要に3回のディスクI / O操作、および3つのメモリルックアップ操作を見つけました。メモリキーは、順序付きリスト構造であるので、あなたは、効率を改善するためにバイナリ検索を使用することができます。とき3回のディスクI / O操作を見つけるためにBツリーの全体的な効率に影響を与える要因を決定しています。
ツリー+ B
B +ツリーは、Bツリーに基づいた最適化は、外部メモリ索引構造を実現するために、それはより適切にすることです、Bツリー内の各ノードは、鍵を持っているデータがあると、メモリの各ページがありますデータが大きい場合にはデータの限られた、少数は、各ノード（すなわち、ページ）は、キーに格納することができる原因となります。これにより、クエリの効率に影響を与えるときにディスクI / O時間も大きい深さにつながるBツリーに格納されるデータの量は、クエリが増加した場合。
B +ツリーのノード内のすべて同じレベルのリーフノードの順に格納された鍵データレコードに応じてだけでなく、大幅に各ノードに格納されたキー値の数を増加させることができるリーフノード情報のキー値を格納しています、還元+高ツリー、B、
B +ツリー上のBツリーに基づいて2つのバリエーションであるが;保存された普通のインデックスは、（1）データは、本リーフノード（マスター鍵ID格納する主キー索引リーフノードでありますデータの行全体）
（2）のデータはノードへのポインタ（好都合範囲参照）の間の
各ディスクは、4つのキーブロックとポインタ情報を格納することができると仮定すると、非リーフノードストアのB +ツリーのでのみ鍵情報、以下に示すようにB +ツリー構造の後に次のようになります。
そこB +ツリーは、ルートノードへのポインタに2つのヘッドポインタは、別のキーワード最小のリーフノードを指し、通常は、環構造は、すべてのリーフノードのうち鎖（すなわち、ノードデータ）です。
したがって、2つの検索操作は、B +ツリー上で実行することができ、一方が他方のルートノード、ランダムサーチからのものである、主キーの範囲を検索するためのものであり、タブを見つけます。
+ BのInnoDBのツリー
のInnoDB IDをインデックスデータとして記憶されている
InnoDBエンジンを使用して、定義ファイルがデータファイルであり、二つのデータ・ストレージ・ファイルを有しています。
B +ツリー構造のIDによってInnoDBはインデックス付け、及びリーフノードに格納レコード
インデックスフィールドは、主キーIDを確立していないそのフィールドがインデックスされ、その後、リーフノードに格納されている場合は、レコードの主キー、主キーであります該当するレコードを検索するためのインデックス
参考リンク：https://blog.csdn.net/m0_37962600/article/details/81005191