以前は、バイナリと複数のツリーの話、良好なパフォーマンスバイナリ木、AVLの木のように、赤、黒の木は非常に優れた構造ですし、データベースインデックスは、理由である、そのようなバイナリツリー構造を使用していませんか？木がより良いパフォーマンス検索を持っているので！現在、ほとんどのデータベースシステムとファイルシステムはBツリーまたはそのB + Treeインデックス構造としてバリアントを使用します。
、B-とB +ツリーの木レビュー
1.B-ツリー
ツリー-B （マルチパス探索木）共通のデータ構造です。ロケーション履歴の中間処理は、このようにアクセス速度を高速化、経験ときBツリー構造を使用して大幅に低減することができます。翻訳によると、Bのバランスは通常は短いと考えられています。このデータ構造は、一般に、インデックスデータベース、より高い全体的な効率が使用されます。
B-ツリーの各ノードは、鍵及びデータを格納するツリーのすべてのノードすなわち、リーフノードポインタがヌルです。
B-ツリー機能：
- ルートノードは、少なくとも2人の子供がいます
- 各非ルート・ノードは、[M]子供持っています。
- 各非ルートノードは[-1、M-1]キーワードを有し、昇順に並ん
- キー[I]及び[I + 1]キーキーの間の子ノードの値である[I]、[I + 1]キーとの間の
- すべてのリーフノードは、同じレベルにあります
B-ツリーの利点：
Bツリーの利点は、複数の表情が、これは、各ノードが鍵を持っている赤黒木ながら、各ノードは、複数のキーを持っている赤黒木特別な理由は、我々が考える、B-ツリーよりも優れているということですBツリーの高さは特に夜間、一般に低いつつデータの増加と、赤黒木の高効率化は、Bツリーのノードのみが、N個のキーを置くことができるので,,完全ですか、減少し続けますこれは、一度分割されました！なぜB-treeは、それを分割しますか？データの増加、Bツリーの特性を維持するためにフルのキーのノードと、それは木の性質を維持するために、ちょうど赤、黒の木とAVL木のように、分割されていますので、同じを回転させると同じ必要があります！
2.B +ツリー
B +ツリーは、変異B-ツリーでも、実質的に同じBツリーに定義されているマルチパス探索木です。アドレスB +ツリーのリーフ・ノードと対応するキーワード格納されたレコードは、インデックスとして使用されるリーフノード上の層。
Bの+の木：データストレージのみリーフノード、リーフノードは、キーツリーのすべてが含まれている、リーフノードは、ポインタを格納しません。
B +木の特徴：
- すべてのキーワードは、リーフノード（密集指数）のリストに表示され、キーワードのリストを注文することを起こります。
- 非リーフノードがヒットすることはできませんで。
- 非リーフノードは、インデックス（索引スパース）のリーフノード、データ記憶層（キーワード）のデータに対応するリーフノードに対応します。
- ドキュメントのインデックス作成システムのためのより適切な。
異なるB-とB +ツリーのツリー：
- 各ノードポインタの上限はない2D、2D + 1。
- ノードは、データ、店舗のみでのキー、すなわち、保存されていないすべてのキーワードをリーフノードに表示されます。
- リーフノードは、ポインタを格納するのではなく、すべてのリーフノードのチェーン・ポインタを増加させます。
B +ツリーの利点：
順次アクセス・ポインタが増加中のB +ツリー、すなわち各リーフノードツリーインデックスの好適なデータ構造のデータベース・システムを実現することになるように、隣接するリーフポインタにノードを追加します。最も重要なのは、木ががっしりしている多くの理由、一般的に、多くの場合、私は、メモリアクセスに関して、インデックスが検索したときに、ディスクI / Oの消費量が得られ、ディスク上のインデックスファイルの形式で保存され、インデックスが大きく、話すがあります。 / Oの高い数桁の消費ので、最も重要な指標の指標として、データ構造のメリットの評価へのアクセスは、ディスクI / O操作の数のプロセスの複雑さを見つけるための時間です。木の小さい高さ、I / Oの回数が少ないです。それはノードデータ内に格納されていないため、一方のノードは、複数のキーを格納することができるように、代わりにBツリーのB +ツリーは、それが、ある理由です。
第二に、決定的な要因インデックス検索速度は何ですか？
データベース内のデータのほとんどは上記のディスク上に格納されているので、一般的には、インデックス自体も素晴らしいですが、ディスクはすべてのメモリに格納することができないので、インデックスは、多くの場合、インデックスファイルの形式で保存されています。最も重要な指標の指標であるので、この場合には、インデックス・ルックアップ・プロセスは、数桁の高い消費へのメモリアクセス、I / Oアクセスに対して、データ構造のメリットのように評価したディスクI / Oの消費量を生成しますディスクI / O操作の複雑さを見つけるプロセスインチ 木の小さい高さ、I / Oの回数が少ないです。言い換えれば、インデックスの構造組織は、アクセスのルックアッププロセスのディスクI / Oの数を最小限に抑えます。
クエリの低い効率をもたらすIO複数のディスク深すぎるバイナリツリー、Bツリー及びB +ツリーの高さをm各子ノードまでを含む、相対二分木、木の高さB及びB +ツリーは比較的低く、それは短いと脂肪！
三、MySQLのストレージエンジンで
MySQLでは、二つの最も一般的に使用されるストレージエンジンはMyISAMテーブルで、InnoDBは、MySQLは、検索エンジンの二世代です。
インデックスそれらの異なる実装を別々のデータのMyISAMデータ格納アドレス、及びインデックスデータ。InnoDBのデータは、データそのものではなく、また、インデックスデータを保存します。
メインとセカンダリのサブインデックスインデックスインデックスは：一般的に主キーのインデックスの主インデックスと呼ばれ、インデックス内の他のキーは、セカンダリインデックスと呼ばれています。
四、MyISAMテーブルはB +ツリーを使用して実装しました
メインインデックス：
図から分かるように、COL1が主キーであり、リーフノードに格納されたデータがアドレスである、アドレスデータが発見されました。
セカンダリインデックス（指標別のプライマリおよびセカンダリインデックスを繰り返すことができるキーです）：
五、InnoDBはB +ツリーを使用して実装しました
メインインデックス：
なお、差分が格納されているのMyISAMとデータフィールドは、すべてのリーフノードデータです。
セカンダリインデックス：
セカンダリインデックスと主屈折率との差をよく見ると、セカンダリインデックスのリーフノードの保存は、主キーであり、これはMyISAMテーブルとInnoDBの間の最大の違いです。
六、最終的にはMyISAMテーブルよりもInnoDBが良かったですか？
MySQLのMyISAMテーブルとInnoDBは、エンジン2つの世代なので、確かにそこにリフトすること、およびInnoDBは最新世代であるだろう、それは最後どこにも優れているのですか？
異なる実際に言及されてに対してBツリーに基づいて実装され、想像B +ツリーへのMyISAMとInnoDBのそのデータ・フィールド及び分離であるノード。
MyISAMテーブルは、私は私のアドレスを変更した場合、すべてではないので、メインインデックスとセカンダリインデックスのB +木は、そうしているファイルの内容のアドレスインデックスとB +ツリーの個別のデータフィールドのリーフノードを提出されています論理的に隣接ノード、必ずしも物理的に隣接しているため、インデックスツリーは、以前に我々はディスク上に頻繁に話すよう読み取りおよび書き込み操作は非効率的で、変更しなければならなかったが、この原則は適用せずにローカルこれは効率が低下になります。
以来、InnoDBが発生し、それは、セカンダリインデックスのリーフノードの主な指標に加えて、データフィールドを作る最初のセカンダリインデックスを通して主キーを見つけ、その後、主キーのすべてのデータのリーフノードを見つけ、主キーを格納している、それは非常にのように見えるが聞こえますトラブルただし、2つのツリーを横断するので、彼らはそれを修正する必要がある場合は、本体のみのインデックス、その他の補助マイクロプリンティングは移動しない変更、および、ツリーの各ノードのための鍵は、我々が与えるデータベースにこれほど少ないのではありませんノードが1024のキーを持っている場合は、木の高さは一般的に非常に低いので、2 B +ツリーの高さは、1024×1024のキーを持っているので、ツリートラバーサルはほとんど無視できる消費想像してみて！
七つの概要
1. なぜB +ツリー？
- ファイルが大きい場合、すべてのメモリに格納されていない、それがディスク上に格納されます
- インデックスの構造組織は、ディスクIのプロセスを見つけるために、アクセス数を最小限に抑えるために/ Oのは、（なぜB - 。/ +ツリーは、親切にディスクアクセスの原則だっ詳細については、以下の分析を参照します）
- ディスクの先読みの局所性の原理を、長さは一般的に先読みページ（ページ）である整数倍である（多くのオペレーティング・システムでは、ページサイズは、一般的に4Kを得ています）
- 各ノードは唯一のI / Oを必要とするようにデータベース・システム・ディスクの巧妙な使用先読み原理、ノードは、ページのサイズに等しく設定されている完全にロードすることができる（これはノードが2つのアレイ、連続したアドレスを持ちます） 。赤黒木この構造、かなり深く、より時間。近い論理ノード（親子）で、物理的に遠く離れた可能性があるため、それがローカルに使用することはできません。
2.なぜBの+ツリーは、B-treeインデックスよりも適しているのですか？
B +ツリーのディスクは、低コストで読み込み、
B +内部ノードポインタ、すなわち、データがノード内に格納されていない、特定のキーワード情報ではありません。そう内部ノードBは、比較的小さい木です。同じディスク・ブロックに格納された同一の内部ノードのキーのすべての場合は、キーワードのディスクブロック数が多くを収容することができます。使い捨ては、あなたがより多くを見つけたいキーワードにメモリに読み込ま。IOは時間が相対的に少なくなり読み書きします。
Bの+ - ツリーより安定したクエリ効率
非エンドポイントは、ファイルの終点ノードの内容が、キーワードで唯一の索引リーフ・ノードではありませんので。だから、任意のキーワードを探すことはリーフノードへのルートからのパスに従わなければなりません。全て同じキーワードクエリ経路長、かなりのそれぞれのデータクエリ効率が得られます。
MyISAMとInnoDBのの3.MySQLどちらも屈折率差
- MyISAMの非トランザクションセーフでは、InnoDBはトランザクションセーフである一方、
- MyISAMテーブルは、テーブルレベルのロック粒度であり、InnoDBは、行レベルのロックをサポート
- MyISAMテーブルは、InnoDBは、フルテキストインデックスをサポートしていませんが、フルテキストインデックスの種類をサポートしています
- MyISAMテーブルが効率がInnoDBのよりも優れている、比較的簡単で、MyISAMテーブルは、小さなアプリケーションを使用することを検討してください
- ファイル形式にMyISAMテーブルを保存し、簡単にクロスプラットフォームで使用します
- 選択操作多数の代替のアプリケーションで実行する場合、高速ストレージおよび検索、および全文検索機能を提供する、非トランザクションテーブルのMyISAM管理
- アプリケーションで実行挿入および更新操作の多数は、選択された場合、特徴ACIDトランザクションサポートを有するトランザクションのためのInnoDB。
私のマイクロチャネル公共数：アーキテクチャの聖書（ID：gentoo666）、共有Java乾燥、並行性の高いプログラミング、人気のある技術的なチュートリアル、および分散型マイクロサービス・テクノロジー、建築、デザイン、ブロック・チェーン・テクノロジー、人工知能、ビッグデータ、Javaのインタビュー質問だけでなく、最先端の情報とそんなに人気があります。ああ毎日更新！
参考文献：