INの回避 制限は非効率的であり、JPAは常にその仕事に適したツールであるとは限りません。次の点を考慮してください。
-
数千のバインドされた値は、潜在的にメガバイトのSQLになります。このSQLをデータベースに送信するには長い時間がかかります。データベースは、「非常に長いINリストの制限と変換：WHERE x IN（,,, ...）」の質問に対するトムの回答 。
-
SQL解析のため、非効率になります。この長いSQLの解析には長い時間がかかるだけでなく、呼び出しごとに異なる数のバインドされたパラメーターがあり、それらは個別に解析および計画されます（それを説明するこの記事 。
-
SQLステートメントにはバインドされたパラメーターのハード制限があります。
ORを繰り返すことができますINを回避するために数回 制限がありますが、ある時点でSQLステートメントの制限に達することになります。
これらのタイプのクエリの場合、通常は一時的なものを作成することをお勧めします。テーブル
。クエリの前に1つ作成し、それにすべての識別子を挿入し、クエリのエンティティテーブルと結合して、INをシミュレートします。 調子。
理想的には、JPAをストアドプロシージャに置き換えることができます。特に、次のクエリでデータベースに戻すためだけにデータベースから数万の識別子を引き出す場合はそうです。