2011-06-28 16 views
11

クエリ中に集計が必要な場合は、SQL Serverがキャッシュを使用するかどうかを再確認します。例えば、SQL Serverの集計パフォーマンス

Select Sum(Field), 
     Sum(Field)/12 
From Table 

うSQL Serverは、すでに最初のフィールドにSum関数を計算してからちょうど秒12で割りしたこと

を知っていますか?または、Sum関数を再度実行してから、12で除算しますか?

おかげ

答えて

8

それは計画が与える

Select 
    Sum(Price), 
    Sum(Price)/12 
From 
    MyTable 

一度計算します

|--Compute Scalar(DEFINE:([Expr1004]=[Expr1003]/(12.))) 
    |--Compute Scalar(DEFINE:([Expr1003]=CASE WHEN [Expr1010]=(0) THEN NULL ELSE [Expr1011] END)) 
    |--Stream Aggregate(DEFINE:([Expr1010]=Count(*), [Expr1011]=SUM([myDB].[dbo].[MyTable].[Price]))) 
     |--Index Scan(OBJECT:([myDB].[dbo].[MyTable].[IX_SomeThing])) 

をこのテーブルには、135万行

+1

+1:計画の良い要約:o) –

+0

ありがとう、計画のためにこれを選んだ。 –

-3

良い質問は、私は答えはノー、それをキャッシュしないしないと思います。

私は約3000カウントのテストクエリーを実行しましたが、それはほんのわずかのテストクエリーよりはるかに低速でした。クエリが単に普通の列を選択するのと同じように遅くなるかどうかをテストしたい場合

編集:OK、速度に影響します。

全体的に、クエリでその集計番号を何回も使用している場合を除き、大丈夫です。プッシュが押されると、結果を変数に保存して、事実の後に数学を行うことができます。

+0

-1 - 時間は、結果をレンダリングするのにかかる時間の指標である、またはメモリから同じ値の3000回出引く、そして場合の兆候を持っていない可能性が結果がキャッシュされるかどうか。 – JNK

+0

が合意した、それが私が編集を入れてそのように述べた理由である。 – Limey

+0

あなたの答えの最初の行はまだ事実上​​明らかに間違っているので、downvoteはそのままだ。 – JNK

3

実行計画によれば、列を再計算しません。

関連する問題