0

リクエストごとに1回だけ実行されるこのクエリがあります。

SELECT SUM(numberColumn) AS total, groupColumn
FROM myTable
WHERE dateColumn < ? AND categoryColumn = ?
GROUP BY groupColumn
HAVING total > 0

myTable列数が12未満で、最大500万行まで成長する可能性がありますが、本番環境では約200万行になる可能性があります。クエリで使用されるすべての列は、を除いて数値でdateColumnあり、とにインデックスがdateColumnありますcategoryColumn。

データベースが適切に最適化されている場合、最新のサーバーでは、このクエリが5秒以内に500万行で実行されると期待するのは合理的でしょうか？

私が尋ねている理由は、500万のデータがなく、今後数年以内に200万に達することさえないからです。クエリが5秒以内に実行されない場合、どこにあるかを知るのは困難です。問題はあります。クエリが大きなテーブルに適していないか、データベースが最適化されていないか、サーバーが十分に強力でないことが原因でしょうか。SUM()基本的にGROUP BY、大きなテーブルを使用するのが妥当かどうかを知りたいです。

ありがとう。

4

2 に答える 2

2

あなたの質問の下のコメントの人々が示唆したように、検証する最も簡単な方法は、ランダムなデータを生成し、クエリの実行時間をテストすることです。dateColumnでクラスター化インデックスを使用すると、合計を計算するために「<」条件では連続ディスクデータのサブセットのみが取得されるため、実行時間が大幅に変更される可能性があることに注意してください。

開発の初期段階にある場合は、データを収集するテーブルとインデックスの構造ではなく、将来的にテーブルから何を取得する必要があるかということに集中することをお勧めします。Webサイト管理者にWeb使用統計を提示した自分の経験を共有できます。サーバーからいくつかのWebページが要求されましたが、それぞれが1つ以上の「カテゴリ」に分類されました。私の最初のアプローチは、いくつかのインデックスを含むログテーブルに各リクエストを収集することでしたが、テーブルは最初の見積もりよりもはるかに大きくなりました。:-)統計が一定のグループ（毎週、毎月、毎年）で分析されたという事実のために、事前定義された週/月/年のグループでリクエストを集約する追加のテーブルを作成することにしました。各リクエストは関連する列をインクリメントしました-列は私の「カテゴリ」を参照していました。これはいくつかの正規化ルールを破りましたが、瞬く間に統計を計算することができました。

于 2012-07-26T17:16:58.867 に答える
1

重要な質問はdateColumn<？調子。古くなったレコードをフィルタリングしていると思います。テーブルにレコードがいくつあるかは実際には関係ありません。重要なのは、この状態がどれだけのレコードを削減するかです。

日付による積極的なフィルタリングと日付によるテーブルのパーティション化を組み合わせると、途方もなく大きなテーブルで驚くべきパフォーマンスを得ることができます。

ちなみに、今後何年にもわたってこれほど多くのデータがヒットすることを期待していない場合は、わざわざ解決しないでください。それまでに、アーキテクチャ、データベースレイアウト、設計、および実装の詳細とともに、ビジネス要件が数十回変更される可能性があります。事前の計画は素晴らしいですが、できるだけ早く十分な解決策を提供し、次のリリースで将来の厄介な問題に対処したい場合があります。

于 2012-07-26T17:07:11.377 に答える