1

0.1 秒ごとに収集されたレコードを含むデータベースがあり、特定の日のデータを 20 分ごとに時間平均する必要があります。そのため、24*3 の値である 20 分ごとに平均化された 1 日分のデータを返す必要があります。
現在、1 日の 20 分間ごとにデータベースに対して個別の AVG 呼び出しを行っています。これは 24*3 呼び出しです。データベースへの接続が少し遅いようで (リモートです)、すべての平均を実行するのに約 5 分かかります。1 日分のデータにアクセスし、それを 20 分ごとに平均化する単一のクエリを実行する方が高速でしょうか? 質問に答えるのに役立つ場合は、平均化する前にデータに算術演算を行う必要があります。つまり、いくつかのテーブル列を乗算します。

4

7 に答える 7

1

一般に、クエリの数を減らすことは良い考えです。クエリで (つまり、データベースで) 可能な演算/フィルタリング/グループ化を集計して実行し、サーバー側 (PHP など) で「反復」計算を実行します。

于 2010-01-12T14:49:58.397 に答える
1

次のように、真夜中からの分数を計算できます。

datepart(hh,datecolumn)*60 + datepart(mi,datecolumn)

これを 20 で割ると、20 分間隔の数値が得られます。たとえば、 interval 、interval 、intervalなどに00:10分類されます。この式を使用すると、次のように 20 分間隔でグループ化できます。000:30115:3046

select
    (datepart(hh,datecolumn)*60 + datepart(mi,datecolumn)) / 20 as IntervalNr
,   avg(value)
from      YourTable
group by  (datepart(hh,datecolumn)*60 + datepart(mi,datecolumn)) / 20

avg次のように、呼び出し内で計算を行うことができます。

avg(col1 * col2 - col3 / col4)
于 2010-01-12T14:54:29.833 に答える
0

1つのクエリでの計算はわずかに高速になります。接続の設定、クエリの解析、ストアドプロシージャの読み込みなど、複数のリクエストのオーバーヘッドについて考えてみてください。

ただし、パフォーマンスが大幅に向上する可能性のある正確な指標があることも確認してください。hughデータベースでの一部の操作は、数分から数時間続く場合があります。

于 2010-01-12T14:58:04.917 に答える
0

可能であれば、テーブルに列を追加し、データをデータベースに投稿するたびに、列の積と間隔インデックス (Andomar の投稿を参照) を計算して保存します。

于 2010-01-12T16:49:10.570 に答える
0

大量のデータを送信していて、接続がボトルネックになっている場合、データをグループ化して送信する方法とタイミングは重要ではありません。56k モデムで 10 分ごとに 100MB を送信する良い方法はありません。データのサイズと帯域幅を把握し、送信できることを確認してください。

それは言った：

まず、ネットワークがボトルネックであることを確認します。その場合は、可能であればより小さなデータ セットで作業し、さまざまなシナリオをテストしてください。一般に、1 つの大きなレコード セットは、半分のサイズの 2 つのレコードセットよりも少ない帯域幅を使用します。

于 2010-01-12T16:08:04.650 に答える
0

それがより速いかどうかを確認するには、測定する必要があります。

ただし、データベースへの接続が遅いため、より高速になるはずです。このようにして、ラウンドトリップの数が合計実行時間に大きな影響を与えます。

于 2010-01-12T14:54:48.620 に答える
0

データベース上のストアド プロシージャはどうですか? データベース エンジンがサポートしていない場合は、スクリプトまたは何かを使用して計算を行い、データベース サーバーに別の「平均」テーブルを作成するのはどうでしょうか。その後、1 日に 1 回だけリモート クライアントから平均を読み取るだけで済みます。

于 2010-01-12T14:55:31.993 に答える