MySQL インデックスの最適化戦略

このセクションの後半では、インデックスを追加するときに使用される戦略を最適化するために、実践的でわかりやすい例を使用してインデックスの実際のトリガーを説明します。

1. インデックスの種類

1.1 B ツリー インデックス

注: 大局的には、すべてバランス ツリーを使用しますが、具体的な実装に関しては、各エンジンが若干異なります。たとえば、厳密に言うと、NDB エンジンは T-tree、Myisam、および innodb を使用し、B-tree インデックスがデフォルトで使用されます

しかし、抽象的に言えば、B-tree システムは「高速にソートされた」ものとして理解できます。検索構造」。 詳細な分析については、Mysql-Index-BTree Type [Simplified] を参照してください。

1.2 ハッシュ インデックス

メモリ テーブルでは、デフォルトはハッシュ インデックスです。 ハッシュの理論的なクエリ時間計算量は O(1) です

質問: ハッシュ検索は非常に効率的であるのに、なぜすべてハッシュ インデックスを使用しないのでしょうか?

答え:

1: ハッシュ関数の計算結果はランダムです。たとえば、ディスクにデータを配置する場合、主キーは id になります。 ID に対応する行はディスク上にランダムに配置されます。

2: 範囲クエリを最適化できません。たとえば、btree では、プレフィックス インデックスを使用できません。 フィールド列「hellopworld」の値にインデックス、クエリを追加します。 xx=helloword の場合は当然インデックスを使用できます。xx=hello の場合はインデックス (左側のプレフィックス インデックス) を使用することもできます。実際には、hash('helloword') と hash('hello') の関係がランダムであるためです。

4: ソートを最適化できないためです。インデックスを通じてデータの場所を取得するには、テーブルに戻ってデータを取得する必要があります

2. Btree インデックスに関するよくある誤解

2.1 where 条件でよく使用される列にインデックスを追加します

例: where cat_id=3 and Price> 100; // 3 番目の列をクエリ、100 元を超える商品

エラー: cat_id、 インデックスは、price に追加されます。

エラー: cat_id インデックスまたは Price インデックスのみを使用できます。これは、独立したインデックス構造であり、同時に使用できるのは 1 つだけであるためです。詳細な配置の説明については、Mysql によるインデックス構造の直感的な図解を参照してください

2.2 複数列インデックスでは、インデックスが機能するには左プレフィックス要件を満たす必要があります。

エラー: 複数の列にインデックスを作成した後、どの列をクエリするかは、インデックス All が役割を果たします

index(a,b,c) を例に挙げます。

III. 結合インデックスの順序は左側のプレフィックスに従います。 SQL ステートメント内の where 条件は、上記のクエリ例 4 と 5 のようにコンテキストがありません。3 のように使用されます。 レイヤーごとのネストを前提として、順序ソートは where 条件には関与しません。実際には、 [where field a order by field a] の問題に注意してください。 [order a] はすでに a に等しいため、誤った命題です。どのサブ順序をランク付けする必要がありますか? 4. 選択クエリ Where では、複数の条件の順序はありませんが、追加するときは順序に注意する必要があります。インデックス、それらは同じです。

5. グループ化におけるグループの仕組み: 最初に order_by ソートを行い、一時テーブルを作成します。インデックスを構築すると、一時テーブルを作成する必要がなくなり、グループに対してインデックスが有効になります

上記は Mysql インデックスの最適化戦略です。さらに関連するコンテンツについては、PHP 中国語 Web サイト (www.php.cn) に注目してください。