web-dev-qa-db-ja.com

VARCHARカラムにインデックスを付けるのは良いアイデア/アプローチですか？

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

関係するテーブルがあります：[〜＃〜]従業員[〜＃〜]および[〜＃〜]メールリスト[〜＃〜]。

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

2つのテーブルは、EMPLOYEE.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秒です。

テーブル数の統計：現在、EMPLOYEEには165,018件のレコードがあり、EMAILLISTには1,810,228件のレコードがあり、両方のテーブルが将来成長すると予想されます。

  1. VARCHARカラムにインデックスを付けるのは良いアイデア/アプローチですか？アプリケーションで以前にVARCHAR列にインデックスを付けなかったため、この質問はすぐに頭に浮かびます。これに関する専門家のアドバイス/提案は高く評価されています。
  2. この現在のクエリとインデックスでは、14秒の応答時間は妥当ですか、それともさらに調整する余地がありますか？このようなテーブルサイズと応答時間に基づいて、他のユーザーのリアルタイムの経験/意見は何ですか？

注：私の実際の要件/ユースケースについて詳しく説明します ここ 。

performancepostgresqlindexquery
33
Gnanam

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

26
xenoterracide

Varchar列自体にインデックスを付ける問題はありません。

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

テーブルは非常に小さく、パフォーマンスはOR句に関連している可能性があります。残念ながら、クエリをどのように構造化しても同じ問題が発生します（そして、PostgresSQLを十分に理解していないため、すみません）

5
gbn

クエリの "OR e2.email IS NULL"の部分を削除してみて、実行速度を確認してください。実行速度が速い場合は、 "union all 」

0
Joe Love