2

*最初の注意として、私は自分のサーバーへの読み取りアクセスしか持っていません。ただ、参考までにたくさん出てくるようですが...

サーバー：DB2（6.1）for i（IBM）

19mil行のテーブルで実行しているクエリがあります（設計はしていません。クエリを実行するだけです）。戻り時間がもう少し合理的になるようにこのクエリを整理するまで、戻りデータを10行（*）に制限してきました。

基本的な設計では、WEEK_ID列とCATEGORY列を使用して、週ごとに販売する製品のカテゴリに関するデータを取得する必要があります。これがサンプルコードです（いくつかの重要なビット####が出ています）。

SELECT WEEK_ID, CATEGORY
FROM DWQ####.SLSCATW
INNER JOIN DW####.CATEGORY
ON DWQ####.SLSCATW.CATEGORY_NUMBER = DW####.CATEGORY.CATEGORY_NUMBER
WHERE WEEK_ID  
BETWEEN 200952 AND 201230 --Format is year/week
GROUP BY WEEK_ID, CATEGORY

その最後の行をコメントアウトすると、254ミリ秒で100行を取り戻すことができます。私がその行を私のリターンに戻すと、私が待つのに我慢していたよりも時間がかかります:-)。（私が待っていた最長時間は10分です。）

この質問には2つの部分があります。最初の質問は非常に初歩的なものです：これは正常ですか？私が凝縮しようとしているのは、50のカテゴリー（大まかに）と140週間（またはそれくらい）です。これは1900万行から凝縮するための多くの情報であることに気付きましたが、クエリを返される10行に制限することで、時間を最小限に抑えることができると期待していました。

そして、私が完全なn00bでなく、実際にこれに数分かかることはない場合、SQLの何が問題になっていますか？

WHEREステートメントの最適化をグーグルで検索しましたが、何も見つからないようです。すべてのリンクと説明は大歓迎です。

そのような初心者の投稿についてお詫びします...私たちは皆どこかから始めなければなりませんよね？

（*）SQLExplorer、私のIDE、SquirrelSQLのEclipse実装を使用します。

4

2 に答える 2

2

group byクエリに集計関数がない場合にサーバーがどのように処理するかわかりません。コメントのあなたの答えに基づいて、私はそれらを追加しようとします：

SELECT
    ...,
    SUM(SalesCost) as SalesCost,
    SUM(SalesDollars) as SalesDollars
FROM
    ...

クエリの残りの部分はそのままにしておきます。

それでも問題が解決しない場合は、インデックスが欠落している可能性があります。WEEK_IDが唯一の列であるか、それとも最初の列であるインデックスがあるかどうかを調べようとします。同じテーブルにすでにインデックスが作成されている別の一時列（つまり、TransactionDateなど）があるかどうかを確認することもできます。whereその場合は、代わりに句でそれを使用できます。

正しいインデックスがないと、データベースサーバーは完全なテーブルスキャンを実行する必要があり、パフォーマンスの問題を説明する可能性があります。3,900万行は、ディスクから読み取るのにそれほど重要ではない時間がかかります。

intまた、クエリで不要なキャストを回避するために、WEEK_IDのデータ型が類似しているかどうかを確認してください。

カテゴリテーブルでのテーブルスキャンを回避するには、Category_Numberにもインデックスが付けられていることを確認する必要があります。（私はそれがそのテーブルの鍵であると思うので、おそらくすでにそうです。）

于 2012-12-12T17:11:25.240 に答える
0

WEEK_ID、CATEGORY（および場合によってはCATEGORY_NUMBER）のインデックスは、それを本当に高速にする唯一の方法であるため、DBOにそれらを導入するように説得する必要があります。

于 2012-12-12T21:49:46.380 に答える