1

ここ Stack や Google ランドでは見つけられない、かなり単純な質問だと思います。次のようなかなり基本的な選択ステートメントがあります。

SELECT
    itemid,
    itemdiscription,
    SUM(quantity)
FROM     mytable
GROUP BY itemid, itemdescription
ORDER BY itemid
LIMIT    250
OFFSET   0;

基本的に、これは 100,000 件以上のレコードのテーブルから取得するか、場合によってはそれ以下ですが、一時テーブルです。私が把握しようとしているのは、信頼できるデータを提供する SUM 関数です。類似したアイテム ID の間に 30k のレコードが存在する可能性があるためです。私の最初の考えでは、これによりクエリが実行され、最初の 250 件の結果のみが返されると考えられていましたが、そうではないかもしれないと考えるようになったので、これがどのように機能するかについてコミュニティに確認を求めることにしました。

私が LIMIT/OFFSET を使用している主な理由は、PHP からクエリを実行しており、これらの値は実行のために反復される変数であるため、大量のメモリを使用する配列を扱っていないためです。

ありがとう！

4

3 に答える 3

1

ドキュメントの状態として、制限 (またはオフセット) は「残りのクエリによって生成される行」に適用されるため、制限またはオフセットを適用する前にクエリの結果を考慮してください。これらの句を適用すると、これらの結果に影響します。

http://www.postgresql.org/docs/9.2/static/queries-limit.html

LIMIT を使用するいくつかの方法の SQL Fiddle を次に示します。

http://www.sqlfiddle.com/#!12/08fa0

于 2012-12-19T22:45:14.103 に答える
0

まず、LIMITは、処理された後、クエリ結果の上で機能します。ただし、サーバーは、結果が同じであると信じている場合、これを最適化できます。たとえば、インデックス付きフィールドのSELECT x FROM t ORDER BY x LIMIT 1場合、サーバーは非常に高速に動作します。x

ただし、パフォーマンスまたはページングの実装のためにここでLIMIT / OFFSETを使用している場合は、アプローチを再考する必要があります。これは、すべての集約フィールドにインデックスが付けられ、LIMITがそれを利用できる場合でも、OFFSETが増加すると、総作業量も増加し、すぐにランタイムがLIMITなしで完全なクエリを実行するのとほぼ同じになるためです-非常にコストがかかります。

OFFSETを非常に低く（できれば0）維持する場合は、複合インデックスを追加することを強くお勧めし(itemid,itemdescription)ます。これにより、特に同じの行が多数ある場合に、クエリの実行がはるかに高速になりますitemid。

于 2012-12-20T03:57:06.433 に答える
0

EXPLAIN表示するクエリ、それがどのように実行されるか。LIMITグループ化後に適用されることがわかります。

于 2012-12-20T11:41:45.950 に答える