1

つまり、20 列のテーブルは、4 列しかないテーブルよりも、特定のフィールド (検索のようなクエリで使用されるフィールド) にインデックスを作成することでより多くの恩恵を受けるのでしょうか?

また、あまり検索しないフィールドにインデックスを追加することの害は何ですか？インデックスを追加することのマイナス点はありますか? ディスク上で占めるサイズだけですか、それとも不要なインデックスを追加するために動作が遅くなる可能性がありますか?

コメントから抜粋

私は Postgres (最新バージョン) を使用しており、多くの LIKE タイプのクエリなどを実行するテーブルが 1 つありますが、クライアントが CRUD にアクセスできるため、値は間違いなく頻繁に変更されます。インデックスのアイデアはできますか？彼らはただの頭痛ですか？

4

2 に答える 2

6

20 列のテーブルは、特定のフィールド (検索のようなクエリで使用されるフィールド) をインデックス化することで、4 列しかないテーブルよりもメリットがありますか?

いいえ、テーブル内の列の数は、インデックスを持つことの利点には関係ありません。

インデックスは、指定された列の値のみに適用されます。クエリがどれだけの利益を得るかに影響を与えるのは、値の頻度です。たとえば、ブール値を含む列はインデックス作成には適していません。これは、値がいずれかの値になる可能性が 50/50 であるためです。すべての行を 50/50 に分割すると、インデックスは特定の行の検索を絞り込みません。

あまり検索しないフィールドにインデックスを追加することの害は何ですか?

インデックスは、使用できる場合にのみデータ取得を高速化しますが、INSERT/UPDATE/DELETE ステートメントの速度に悪影響を及ぼします。インデックスは、その価値を維持するためにメンテナンスも必要です。

于 2010-11-17T05:00:21.717 に答える
1

LIKE クエリを実行している場合、とにかくインデックスがあまり役に立たないことに気付くかもしれません。インデックスはこのクエリを改善するかもしれませんが...

select * from t23
where whatever like 'SOMETHING%'
/

...これらのクエリのいずれかでインデックスが役立つ可能性は低いです...

select * from t23
where whatever like '%SOMETHING%'
/

select * from t23
where whatever like '%SOMETHING'
/

フリー テキスト フィールドがあり、ユーザーがあいまい一致を必要とする場合は、Postgres のフル テキスト機能を確認する必要があります。これは、LIKE ではなく MATCH 演算子を使用し、特殊なインデックス タイプを必要とします。 詳細をご覧ください。

全文索引は通常のものよりも複雑であり、関連する設計上の決定は単純ではないという落とし穴があります。また、一部の実装では、追加のメンテナンス作業が必要です。

于 2010-11-17T07:37:18.803 に答える