BTREEの利点は？
USING BTREE句なしでインデックスを作成します。 [〜＃〜] btree [〜＃〜]インデックスを使用する利点はありますか？
CREATE INDEX `SomeName` USING BTREE ON `tbl_Name`(`column_name`);
BTREEはデフォルトのインデックス方式です。安全に省略できます。
まず、使用するストレージエンジンによっては、選択肢がない場合があります（たとえば、InnoDBはインデックスにBTREEのみを使用しています）。
また、BTREEは、ほとんどのストレージエンジンのデフォルトのインデックスタイプです。
現在...代替のインデックスタイプを使用すると、パフォーマンスが向上する場合があります。 HASHインデックスが役立つ場合があります（比較的まれなケースです）。 HASHインデックスが作成されると、BTREEインデックスも作成されることに注意してください。これは、ハッシュインデックスが同等の述語しか解決できないという事実に一部起因しています。 （WHERE Price> 12.0などの条件はハッシュインデックスで処理できませんでした）。
つまり、暗黙的に（BTREEが使用されるストレージのデフォルトである場合）、または明示的に、BTREEを使用し続けます。他のタイプのインデックスについて学び、必要が生じることを知ってください。
編集：（代替インデックスタイプが使用される可能性がある検索の場合）
事実上、 [〜＃〜] rtree [〜＃〜] インデックスの場合はかなり単純です。これらは、MySQLで、 "SPATIAL"データベース のコンテキストでのみサポートされます。つまり、地理位置コンテキストを含むデータベースなどです。 GISモデルのポイントおよびその他のオブジェクトとして）。
HASHインデックスはより一般的であり（特定のアプリケーションやデータ型に限定されません）、一般に、ハッシュの直感的な理解に従って、ハッシュが古いが忠実なBTREEをいつ上回る可能性があるかについてのヒントを得ることができます。前に示したように、これは通常、等しい述語で検索される列を意味します。 MySQL内の効果的な実装によっては、比較的短いルックアップテーブルなどが役立つと思います。
使用しているストレージエンジンによって異なります。ほとんどの場合、BTREEがデフォルトであるため、BTREEを指定しても実際には何も変更されません。 MEMORY/HEAPやNDBなどのストレージエンジンの場合、デフォルトではHASHインデックスがデフォルトで使用されます。
詳細については、こちらをご覧ください こちら
BツリーまたはHASHインデックスがパフォーマンスの観点から有利であるかどうかは、データとそれにアクセスする方法によって異なります。クエリが正確に1つの行または散在する個々の行をターゲットにすることがわかっている場合は、HASHインデックスが役立つ場合があります。それ以外は、データが並べ替えられ、範囲クエリや複数行を返すクエリがより効率的になるため、一般的にBTREEインデックスを好みます。
バランスの取れた木を検索するということは、すべての葉が同じ深さにあることを意味します。滑走路ポインターのオーバーヘッドはありません。実際、さらに大きなBツリーでも、特定のキーを見つけるために少数のノードを取得する必要があることが保証されます。たとえば、ノードごとに50個のキーを持つ10,000,000個のキーのBツリーでは、キーを見つけるために4つを超えるノードを取得する必要はありません。 Bツリーは、インデックス内のデータへの迅速なアクセスを可能にするインデックスの特別なデータ構造形式です。このデータ構造のプロパティの1つは、インデックスが常にバランスが取れていることです。つまり、最下位レベルの各ノードが等距離にあります。最上位ノードまたはツリーのルートノードから。インデックスの両側に同じ数のノードがあります。最下位レベルのノードはリーフノードと呼ばれます。他のすべてのノードはブランチノードと呼ばれます。ブランチポイント他のブランチまたはリーフノードへ。リーフノードは、インデックス付きの列の値と、それらの値を持つ個別の行を指すROWIDを格納します。実際の分布は、特定の値に到達するためにトラバースする必要のある必要なレベルの数を減らすことを全体的な目標として、Bツリーの値の各範囲のデータ値の数に依存します。 Bツリー構造の利点は次のとおりです。
- すべてのリーフブロックは同じ深さ（値の数）です。
- Bツリーの高さは通常、かなり小さいです。場合によっては、ルートノードが唯一のリーフノードであり、高さは1です。テーブルに挿入される行が増えると、これに対応するためにインデックスを増やす必要があります。 100万行を超えるテーブルでは、BツリーIDEXの高さは通常3です。最も大きいテーブルでは、高さは4になります。つまり、最大のテーブルでも、4ブロックで検索できます。あなたが探している行のROWID、これは非常に効率的です。
- ランダムに入力されたデータの場合、Bツリーは自動的にバランスを保ちます。実際、Bツリーはどのデータが入力されてもバランスを保ちます。
- Bツリーインデックスのすべてのブロックは（平均して）4分の3がいっぱいであり、再構築せずに挿入できます。 5.Bツリーは、すべてのタイプの選択に対して優れたパフォーマンスを提供します。 6.挿入、更新、削除は、Bツリー構造で効率的である傾向があります。 7.Bツリーのパフォーマンスは、テーブルが小さいものから大きいものまで最適なままです。
簡単に言うと、SQLがそのフィールドでLIKEステートメントを使用している場合、BTREEインデックスを使用するとハッシュインデックスよりもパフォーマンスが向上するはずです。そのフィールドに対して等しい（=）ステートメントを使用している場合は、ハッシュインデックスを使用してください。