非常に単純なクエリでORDER BY FIELDのdb INDEXが役に立たない-それでも応答が遅くなりますか？
200Kレコードを非常に遅い（20秒）返す非常に単純なクエリがあります。
SELECT * FROM TABLE ORDER BY ID DESC
私がやれば
SELECT * FROM TABLE
それは迅速な結果を返します。
そのフィールドID（ALLOW REVERSE SCANS）でINDEXを作成しましたが、それでも非常によく似た応答が返されます。どこに問題がありますか？このクエリの停滞の原因は何ですか？ staticticsとインデックステーブルのメタデータを更新しました。
このORDER BY FIELDでINDEXが役に立たないのですか？
私のサーバーには8GBのRAMがあります。バッファー・プールの値は128MBです。私はそれを1 GBに調整しましたが、それでもあまり進歩していません。
DB2データベースを使用しています。
構成パラメーターには次の値があります：（SORTHEAP）= AUTOMATIC（164）および（SHEAPTHRES_SHR）= AUTOMATIC（824）。 （SHEAPTHRES）=0。多分それらを調整する必要がありますか？
これは本番稼働中のシステムであるため、サポートに大変感謝しています。
ありがとうございました
さて、まず最初にSELECT *はインデックスの使用をほとんど無効にします。 DB2は、テーブル全体が必要であることを認識し、テーブルスキャンを実行します（それ自体が高価になる可能性があります）。
その後、ORDER BYを実行します。これにより、DB2はスキャンしたばかりのテーブルでSORTを実行します（別の負荷の高い操作）。したがって、2つの高価な操作が次々に発生します。
もう1つ..... IDが主キーの場合...すでに内部でインデックスが作成されています。 （これもSELECT *で無視されます）。これで、おそらくディスク領域を占有している2番目のインデックスができました。 （主キーを含む一意の制約を持つフィールドと同様に、DB2は自動的に一意のインデックスを作成します。）
最初に、これが実際に言っているのは、悪いクエリです（それを置く他の方法はありません）。 SQLに追加する述語はありますか？ WHERE句で選択しているものを削減できる場合、またはSELECTのすべての列が必要ない場合は、それらの列とその上に1つまたは複数のインデックスを作成できます。役立つだろう。
DB2が使用したコストとクエリプランを確認できるように、このクエリに対してEXPLAINを実行することをお勧めします。次に、インデックスなどをテストするときに、DB2がインデックスを利用するかどうかを選択できます。これが最も効率的な方法です。