☰

SQL Group By Year、Month、Week、Day、Hour SQLと手続き型のパフォーマンスの比較 質問する

tag-icon • tag-icon sql sql-server performance
SQL Group By Year、Month、Week、Day、Hour SQLと手続き型のパフォーマンスの比較 質問する

大量のレコードを年から時間までの期間ごとにグループ化するクエリを作成する必要があります。

私の最初のアプローチは、C# で期間を手順的に決定し、それぞれを反復処理して SQL を実行し、その期間のデータを取得して、データセットを構築していくというものでした。

SELECT Sum(someValues)
FROM table1
WHERE deliveryDate BETWEEN @fromDate AND @ toDate

その後、Year()、Month()、Day()、datepart(week, date)、datepart(hh, date) を使用してレコードをグループ化できることを発見しました。

SELECT Sum(someValues)
FROM table1
GROUP BY Year(deliveryDate), Month(deliveryDate), Day(deliveryDate)

私の懸念は、グループ化で datepart を使用すると、datetime フィールドのインデックスを効率的に使用できないため、一定期間にクエリを複数回実行するよりもパフォーマンスが低下することです。これが本当かどうかについて、何かご意見はありますか?

ありがとう。

ベストアンサー1

パフォーマンスに関することなら何でも測定

2 番目のアプローチのクエリ プランを確認すると、明らかな問題 (必要ないことがわかっている場合の完全なテーブル スキャン) が事前にわかりますが、測定に代わるものはありません。SQL パフォーマンス テストでは、適切なサイズのテスト データを使用して測定を行う必要があります。

これは複雑なケースであるため、単一のクエリを実行する 2 つの異なる方法を単純に比較するのではなく、単一のクエリ アプローチと反復的なアプローチを比較しているため、環境の側面が実際のパフォーマンスに大きな役割を果たす可能性があります。

具体的には

  1. アプリケーションとデータベース間の「距離」は、1つの大きなクエリアプローチと比較して、各呼び出しの待ち時間が無駄になるためです。
  2. 準備されたステートメントを使用しているかどうか（各クエリでデータベース エンジンに追加の解析作業が発生します）
  3. 範囲クエリの構築自体にコストがかかるかどうか（2に大きく影響される）

おすすめ記事