0

Sql Server 2008にテーブル「TRANSACTION」があります。このテーブルには、1秒間に約6レコードが挿入されます。(金融取引表なので) ということで、1日で50万件のレコードが挿入されます。 テーブルは毎週分割されます。

このテーブルは、多くの種類の選択 (もちろん NOLOCK を使用)、挿入、更新操作に頻繁に使用されます。

以下のクエリは、同じテーブルに対する他の重要な選択、挿入、更新操作を遅くする可能性があると思いますか? 以下のクエリが長すぎても、このクエリはテーブルをロックしないため、他の選択クエリの速度が低下することはないと思います。しかし、確信が持てないので、あなたに尋ねます。

選択リストの列はテーブルで索引付けされていないことに注意してください。

SET @END_DATE = GETDATE()

SET @START_DATE = DATEADD(HOUR, -24, @END_DATE) 

SELECT Column1, Column2, Column3, Column4, COUNT(*) FROM [TRANSACTION] WITH(NOLOCK)
WHERE TRANSACTION_DATE BETWEEN @START_DATE AND @END_DATE
GROUP BY Column1, Column2, Column3, Column4
4

2 に答える 2

3

サーバーでクエリを実行すると、CPU / メモリ / IO が使用されるため、本質的に、実行するすべてのクエリが実行中の他のクエリに影響を与える可能性があります。

間違いなく、自分の数値から最大 50 万行を読み取ることになります。行サイズを計算すると、このデータが格納されるページ数を大まかに把握することさえできます。クエリ プランと照合して、少なくともフル パーティション スキャンを実行していないことを確認する必要があります。そうしないと、350 万行がメモリにスキャンされます。

それによって SLA の範囲外になりますか? それを判断する方法はありません。適切な負荷テストを通じて判断できるのはあなただけです。

于 2012-01-18T12:12:00.400 に答える
0

明らかに、サーバー上のすべての操作が多かれ少なかれ遅くなります。

クエリの実行中にロックされる唯一のクエリは、テーブルに対するスキーマ変更クエリです。

個人的には、列 Column1、Column2、Column3、Column4、Transaction_date にインデックスを作成して、次のようにグループ化を高速化することをお勧めします。

CREATE INDEX iName on [TRANSACTION](Column1, Column2, Column3, Column4, Transaction_date)
于 2012-01-18T12:19:48.237 に答える