Bir VARCHAR sütununu indekslemek iyi bir fikir midir?

PostgreSQL v8.2.3 kullanıyoruz.

İlgili tablolar var: EMPLOYEE ve EMAILLIST .

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

2 tablo, EMPLOYEE.EMAIL1 veya EMPLOYEE.EMAIL2'nin eşleşen bir girişi yoksa, bu satırların döndürüleceği şekilde birleştirilir.

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

Kolon EMAILolan varchar (256) ait EMAILLISTtablo endekslenir. Şimdi, yanıt süresi 14 saniyedir.

Tablo sayısı istatistikleri: Halen, EMPLOYEE 165.018 kayıt aldı ve EMAILLIST 1.810.228 kayıt aldı ve her iki tablonun da gelecekte büyümesi bekleniyor.

1. Bir VARCHAR sütununu indekslemek iyi bir fikir midir? Bu soru başvurumuzda daha önce bir VARCHAR sütununu dizine eklemediğimiz için hemen aklıma geldi. Bu konuda uzman tavsiyesi / öneri çok takdir edilmektedir.
2. Bu güncel sorgu ve indeks ile, 14 saniyenin tepki süresi makul veya daha fazla ayarlama için herhangi bir kapsam var mı? Bu tür tablo boyutuna ve yanıt süresine dayanan diğer kullanıcıların gerçek zamanlı deneyim / görüşleri nelerdir?

NOT: Gerçek gereksinim / kullanım durumum burada ayrıntılı olarak açıklanmıştır .

Buna göre sorgulama yapacaksanız varchar sütununu dizine eklemede yanlış bir şey yoktur. Ancak, bazı endekslerin ve tek bir alanda ne kadar endeksleyebileceklerinin bir sınırı olduğunu lütfen unutmayın. Örnek, sınırsız miktarda metin içerebilen bir sütunu dizine ekleyemezsiniz. Bununla birlikte, varchar (256) üzerinde bir indeks oluşturabilirsiniz. Deneyin ve yardım edip etmediğini görmek için sorgu performansınızdaki iyileştirmeleri analiz edin.

Varchar sütununu bu şekilde indeksleyen hiçbir sorun yoktur.

Bunun bir sorun olabileceği yer, milyar satırlık tabloda FK olarak varchar sütununa sahip olduğunuz zamandır. Daha sonra PK ve FK için bir vekil anahtarınız olurdu, fakat yine de doğal varchar anahtarında benzersiz bir kısıtlama / indekse ihtiyacınız olacak.

Tablolarınız oldukça küçük ve performans OR cümlesiyle ilgili olabilir. Maalesef, aynı sorun sorguyu nasıl yapılandırdığınızdan bağımsız olarak geçerlidir (ve PostgresSQL ile ilgili çok fazla bilgi edinebilecek kadar aşina değilim)

Sorgunuzun "OR e2.email IS NULL" bölümünden kurtulmayı deneyin ve ne kadar hızlı çalıştığını görün. Daha hızlı çalışırsa, "tümü birliği" ile daha hızlı çalıştırabilirsiniz.