Varchar列にインデックスを作成するのは良いアイデア/アプローチですか？

dba.stackexchange https://dba.stackexchange.com/questions/788

質問

PostgreSQL v8.2.3を使用しています。

関係するテーブルがあります： 従業員 と エマイリスト.

Table 1: EMPLOYEE (column1, column2, email1, email2, column5, column6)
Table 2: EMAILLIST (email)

2つのテーブルは、従業員.email1またはEmployee.email2が一致するエントリを持たない場合、それらの行が返されるように結合されます。

SELECT employee.email1, employee.email2,
        e1.email IS NOT NULL AS email1_matched, e2.email IS NOT NULL AS email2_matched
   FROM employee
   LEFT JOIN emaillist e1 ON e1.email = employee.email1
   LEFT JOIN emaillist e2 ON e2.email = employee.email2
 WHERE e1.email IS NULL OR e2.email IS NULL

桁 EMAIL それはそうです Varchar（256） の EMAILLIST テーブルはインデックス化されています。これで、応答時間は14秒です。

テーブルカウント統計：現在、従業員は165,018のレコードを取得しており、エマイリストは1,810,228のレコードを持っており、両方のテーブルが将来成長すると予想されています。

  1. Varchar列にインデックスを作成するのは良いアイデア/アプローチですか？この質問は、アプリケーションで以前にVarchar列にインデックスを付けたことがない理由のために、すぐに私の心にぶつかります。これに関する専門家のアドバイス/提案は非常に高く評価されています。
  2. この現在のクエリとインデックスを使用すると、14秒の応答時間が妥当ですか、それともさらに調整するための範囲はありますか？この種のテーブルサイズと応答時間に基づいて、他のユーザーのリアルタイムの経験/意見は何ですか？

ノート： 私の実際の要件/ユースケースは詳細に説明されています ここ.

役に立ちましたか？

解決

Varchar列に基づいてクエリを実行する場合、Varchar列のインデックス作成には何の問題もありません。ただし、一部のインデックスに制限があり、単一のフィールドでどれだけインデックスできるかに留意してください。例無制限の量のテキストを含めることができる列をインデックス化することはできません。ただし、問題なくVarchar（256）でインデックスを実行できるはずです。それを試して、クエリのパフォーマンスの改善を分析して、それが役立つかどうかを確認します。

他のヒント

そのようなvarchar列のインデックス作成に問題はありません

問題になる可能性があるのは、Varchar列を10億行のテーブルにFKとして持っている場合です。その後、PKとFKの代理キーがありますが、Natural Varcharキーには一意の制約/インデックスが必要です。

テーブルは非常に小さく、パフォーマンスはOR句に関連している可能性があります。残念ながら、クエリをどのように構成しても同じ問題が当てはまります（そして、私はPostgressQLに十分に精通していませんでした。

クエリの「またはe2.emailはnull」を取り除いて、それがどれだけ速く実行されるかを確認してください。それがより速く実行されれば、「ユニオンオール」でより早く実行できる場合があります

ライセンス： CC-BY-SA と 帰属
所属していません dba.stackexchange
scroll top