2

単純なテーブルuser_id（INT）、date（DATE）、およびearnings（FLOAT）があるとします。このテーブルにインデックスを付ける方法を決定しようとしています。

現在、PRIMARYキーをuser_id、に設定していdateます。

ただし、すべてのクエリがこのキーを使用しているわけではありません。以下にいくつかのクエリ例を貼り付けました。これらはすべて頻繁に実行されます。

SELECT SUM(earnings) FROM stats WHERE user_id=? //Get total earnings
SELECT SUM(earnings) FROM stats WHERE user_id=? AND date between ? AND ? //Get earnings for date range

SELECT user_id FROM stats WHERE date=$today ORDER BY earnings DESC LIMIT 0,5 //Get todays highest earners
SELECT user_id FROM stats WHERE date>$month ORDER BY earnings DESC LIMIT 0,5 //Get months highest earners

ご覧のとおり、上位2つのクエリはインデックスを適切に使用していますが、次の2つは使用していません。

にインデックスを作成することを考えていましたが、すでにインデックスに含まれているためdate、earnings奇妙に感じます。dateこれは正しい解決策ですか？

そうでない場合、このテーブルにインデックスを付けるための最良の方法は何ですか？

4

2 に答える 2

1

日付、収益にインデックスを作成することを考えていましたが、日付がすでにインデックスに含まれているため、奇妙に感じます。

必要に応じて、同じ列を複数のインデックスに含めてもかまいません。にインデックスを作成することdate,earningsは間違いなくOKですが、dateおそらく1つのインデックスで十分です。また、インデックスdateを作成してuser_id個別に検討し、2番目のクエリがほぼ同時に実行されるかどうかを確認することもできます（実行する必要があります）。

于 2013-03-24T00:47:32.817 に答える
0

これは、日付述語の結果であるデータのサイズによって異なります。それが大きい場合（数千のレコード）、ORDER BY収益のインデックスから大きな利益を得ることができます。比較的小さい場合は、インデックスのメリットがあまり見られない可能性があります。実際、このテーブルで頻繁に発生する場合は、挿入、更新、および削除に対して不利益を被っている可能性があります。

あなたの例では、のみに述語がある場合、複合キーインデックスは左から右に機能するためdate、の複合主キーは(user_id, date)役に立ちません。つまり、とにインデックスルックアップがuser_idありますが、単独でuser_id, dateはありませんdate。

トピックから外れていますが、float通貨に適したデータ型ではありません。

于 2013-03-24T00:48:36.207 に答える