Liferay Supportは、特定のサードパーティ製品を他の製品よりも推奨または承認するものではありません。 Liferayは、これらの製品に関して、ここに記載または参照されているいかなる指示に対しても責任を負いません。 これらの原則の実行は、加入者の責任において行われるものとします。
この記事は、 SELECT * FROM table_ WHERE column_ = ? whose のようなSQLクエリを実行する際のDB2の既知の問題を文書化したものです：
- つまり、Service Builder の定義には、一意ではないインデックスを生成する一意ではない非コレクション ファインダーがあります。
- テーブル table_ のレコード数が数十万件である
- column column_のすべての値がデフォルト値に設定される（数値型の場合、デフォルト値は0）。
このタイプのクエリの具体例は、 SELECT Group_.* FROM Group_ WHERE Group_.liveGroupId = ? 膨大な数のサイトがあり、そのどれもがローカルステージング下にないものである。
この動作の背景には、非ユニークインデックスを使用した方が性能が良いにもかかわらず、DB2プランナーがテーブルのサイズを考慮せずにフルテーブルスキャンを行うという判断を下していることがあります。
db2 runstats on table table_ というコマンドを実行しても、クエリの実行プランに違いはありません。
解像度
ステータス修正しない / 回避策あり
この問題はDB2プランナー特有のもので、上記のような特殊なシナリオでしか再現できないため、 、修正されることはありません。
回避策としては、対象テーブルの属性 VOLATILE を true に設定することで、一意でないインデックスを強制的に使用させることができます。
これは、すでにインデックスを使用している現在のクエリでは何の影響もありませんが、インデックスを使用しない他のいくつかのクエリのパフォーマンスには若干のペナルティがあるかもしれません。
追加情報
- 関連チケット: LPS-81265
- DB2 の記事 インデックスアクセスの好感度アップ