2

現在、招待を追跡するために使用するテーブルがあります。インデックス化された電子メール フィールドがありますが、ユーザーが新しいレコードの電子メールを追加するときに指定できる 3 つのオプション キーもあります。重複は許可されないため、電子メールとオプションのキーが既に存在するかどうかを照会する必要があります。現在、キーが指定されている場合、キーは select ステートメントにのみ追加されます。通常、メールのみが指定され、インデックスを使用するとかなり迅速に動作します。キーが追加されると、パフォーマンスが低下します。

3 つのインデックスを追加すると、他の操作のパフォーマンスに影響しますか? この場合、パフォーマンスに影響を与えたくないため、キーはおそらくあまり使用されません。

  • 電子メール、キー 1
  • 電子メール、キー 1、キー 2
  • 電子メール、キー 1、キー 2、キー 3

もう 1 つのアイデアは、キーを 1 つ追加することです。

  • 電子メール、キー 1、キー 2、キー 3

次に、ルックアップで常に 3 つのキーすべてを使用します (例: key1 = mykey AND key2 is NULL AND key3 is NULL)。

関連項目

完全な重複投稿

4

4 に答える 4

3

個人的には、このアプローチをお勧めします。

すべてをカバーする単一のインデックスを使用してメソッドを試してください。正しく思い出せば、含まれている列の最初のクエリのみを実行してもうまく機能します。インデックスを配置したら、Index Advisor を実行します。

次に、別のルートを試して、繰り返します。

それは本当にあなたのデータに依存します。

私は通常、最も頻繁に使用されるキーから始めて、1 つのカバリング インデックスでうまくいくことができました。

于 2008-10-16T18:26:56.560 に答える
2

これは、テーブルが更新される頻度と、インデックスがどれほど複雑かによって異なります。インデックスの作成に夢中になると、レコードが挿入/更新/削除されるたびに、その情報を反映するためにすべてのインデックスを変更する必要があります。

インデックスを 3 つだけ配置し、それらが比較的単純であれば、問題はないはずです。

于 2008-10-16T18:25:01.353 に答える
0

私は間違っているかもしれませんが、次のように付け加えると信じています：

  • 電子メール、キー 1、キー 2、キー 3

クエリが「email」、「email/key1」、「email/key1/key2」などを使用している場合、不足しているフィールドに Null 値を指定する必要なく、ほとんどのデータベースがそれをインデックスとして使用します。

于 2008-10-16T18:30:36.163 に答える
0

他の人が言ったように、ほとんどのデータベースは、a、a と b、または a、b と c だけを検索するときに、インデックス "a、b、c" を使用します。また、多くの場合、テーブルごとに 1 つのインデックスのみを使用します。したがって、「email、key1、key2、key3」を追加するのがおそらく最適です。

つまり、EXPLAIN を使用して、実際に何が起こっているのかを調べてください。クエリが使用しているインデックスがある場合は、そのインデックスを確認してください。すべてのデータベースには癖があります。

于 2008-10-18T08:27:25.537 に答える