複数または単一の化合物インデックス

Question

id,a,b,c,d,e,f,gのテーブルがあり、約100万行あります。次に、複数の組み合わせで条件が複数のクエリを作成することができます。 たとえば、a AND b AND eまたはa AND f AND gまたはe AND f AND gです。

すべての組み合わせを考慮すると、複数の複合インデックスを作成する必要がありますが、a,b,c,d,e,f,gの範囲が[1,10]なのでゼロでない場合はどうなりますか？

1は、単に開始変数ごとに単一の化合物を作ることができるようにa,b,c,d,e,f,gとb,a,c,d,e,f,gなど。とクエリ時間の間に

#b and e have not been chosen 
    SELECT * FROM WHERE a=3 AND b!=0 AND c=4 AND d=5 AND e!=0 AND f=1 AND g=9 
    #I think you get the logic 

ような何かを、このような手順では、mysqlはまだ私を複合インデックスを使用するか、または行うことができでした複合インデックスのすべての可能な組み合わせを作成する必要があります。

最終結果ではなく、7

Answer 1

ことができる場合、MySQLが順番に複合インデックスを使用するよりもずっと高い左組み合わせのpossiblesの数7にインデックスの数を減らすことになります。したがって、データがいくつかのタクソノミを表す場合、単一のインデックスが行います。のは、顧客がステータスプレミアムまたは通常のビジネスや個人のいずれかを入力し、指定した郵便番号に住んでいる、とすることもできるとしましょう、そして

SELECT * FROM customer 
WHERE type = 'business' 
AND postal_code = '12345' 
AND status = 'premium'; 

のようなクエリが構築された複合キーに基づいてインデックスを使用することができるだろうtype + postal_code + statusである。 statusがわからない場合は、インデックスが有効です。しかし、のみがpostal_codeではなくtypeでない場合、インデックスは使用されません。

しかし私はStrawberryのコメントに同意します - これは標準的なリレーショナルスキーマでは通常問題ではありません。テーブルにいくつかの外部キーを持つことは珍しいことではありませんが、データキューブや他の特別なデザインを構築していない限り、この問題はおそらく7つのフィールドではありません。

しかし、これが実際の問題である場合は、各インデックス付きフィールドの値を考慮してください。ほとんどのクエリで、何千ものインデックスを使用して数千の行を絞り込むことができれば、最終的なスキャンは簡単です。 EXPLAIN PLANを試して、どの点でほとんどのクエリで問題がなくなるかを確認します。

インデックスを維持するコストは簡単かもしれません。高度にチューニングされたトランザクションシステムでは、1つの挿入、更新、または削除により、N + 1の書き込みが行われます.1つは行用、もう1つは各インデックス用です。ほとんど読んでいるなら、これはうまくいくかもしれません。そうでない場合、複合キーの組み合わせによっては、書き込み回数を減らすことによって潜在的にいくつかの利点があります。

しかし、私は数十年以上にわたりリレーショナルデータベースを扱ってきました。このシナリオが発生するケースは、ほとんどの場合、スキーマ設計を再考することによって解決されました。私は複合キーが、典型的なリレーショナルでよく標準化されたスキーマで複数のインデックスよりも意味をなさないケースを思い出しています。