1

次のようなクエリに大きく依存する Postgres データベースに Rails アプリがあります。

SELECT DISTINCT client_id FROM orders WHERE orders.total>100

基本的に、特定の条件を満たす注文があるすべてのクライアントの ID が必要です。ID だけが必要なので、これは結合を使用するよりもはるかに高速であると考えました。

「合計」列にインデックスを追加するとメリットがありますか? 挿入速度は気にしません。クエリを非常に高速に実行する必要があるだけです。

4

3 に答える 3

4

次の複数列インデックスが最速であると予想されます。

CREATE INDEX orders_foo_idx ON orders (total DESC, client_id);

PostgreSQL 9.2 では、さらに多くのメリットが得られる可能性があります。「インデックスのみのタプル」機能を使用すると、有利な状況 (最後のVACUUM.

DESCこの場合ASCはほとんど問題になりません。B ツリー インデックスは、ほぼ同じ効率で両方向に検索できます。

于 2012-12-09T19:44:24.873 に答える
1 
>  I only need the id, so I figured this is way faster than using joins.

確かに、この場合、最初に結合の使用を検討する理由がわかりません。

cmotley が言ったように、このクエリの合計列にインデックスが必要になります。ただし、最適なパフォーマンスは、実行しているクエリによって異なります。たとえば、このクエリの場合、このテーブル構造では、次のようにインデックスを作成するのが最速です。

CREATE INDEX IX_OrderTotals ON orders (total, client_id)

インデックスに client_id を含めることで、client_id 列にカバード インデックスと呼ばれるものを作成します。これにより、データベース エンジンはデータをフェッチするためにバックグラウンドで行を検索する必要がなくなります。

于 2012-12-09T19:46:46.977 に答える
1

絶対。合計列にインデックスがないため、このクエリにはテーブル スキャンが必要です。合計列にインデックスがある場合、インデックス シークとキー ルックアップが必要になります。これにより、テーブルのサイズが大きくなるにつれて、クエリのパフォーマンスが大幅に向上します。

于 2012-12-09T19:41:28.700 に答える