it-swarm.asia

Apakah itu ide / pendekatan yang baik untuk mengindeks kolom VARCHAR?

Kami menggunakan PostgreSQL v8.2.3.

Ada tabel yang terlibat: [~ # ~] karyawan [~ # ~] dan [~ # ~] emaillist [~ # ~].

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

2 tabel digabungkan sedemikian rupa sehingga jika EMPLOYEE.EMAIL1 atau EMPLOYEE.EMAIL2 tidak memiliki entri yang cocok, baris tersebut akan dikembalikan.

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

Kolom EMAIL yang merupakan varchar (256) dari EMAILLIST tabel diindeks. Sekarang, waktu respons adalah 14 detik.

Statistik jumlah tabel: Saat ini, EMPLOYEE telah mendapatkan 165.018 catatan & EMAILLIST telah mendapatkan 1.810.228 catatan, dan kedua tabel diharapkan akan tumbuh di masa mendatang.

  1. Apakah itu ide/pendekatan yang baik untuk mengindeks kolom VARCHAR? Pertanyaan ini langsung muncul di benak saya karena alasan kami belum mengindeks kolom VARCHAR sebelumnya di aplikasi kami. Saran/saran ahli tentang hal ini sangat dihargai.
  2. Dengan kueri dan indeks saat ini, waktu respons 14 detik masuk akal atau apakah ada ruang untuk penyetelan lebih lanjut? Apa pengalaman/pendapat real-time pengguna lain berdasarkan jenis tabel ini dan waktu respons?

CATATAN: Persyaratan aktual/kasus penggunaan saya dijelaskan secara rinci di sini .

33
Gnanam

Tidak ada yang salah dengan mengindeks kolom varchar jika Anda akan melakukan kueri berdasarkan itu. Namun harap diingat bahwa ada batasan untuk beberapa indeks dan seberapa banyak mereka dapat mengindeks dalam satu bidang. Misalnya Anda tidak dapat mengindeks kolom yang dapat berisi teks dalam jumlah tidak terbatas. Namun Anda harus dapat melakukan indeks pada varchar (256) tanpa masalah. Cobalah, dan analisis peningkatan kinerja kueri Anda untuk melihat apakah itu membantu.

26
xenoterracide

Tidak ada masalah pengindeksan kolom varchar seperti itu

Di mana itu bisa menjadi masalah adalah ketika Anda memiliki kolom varchar sebagai FK di tabel miliar baris. Anda kemudian akan memiliki kunci pengganti untuk PK dan FK, tetapi Anda masih membutuhkan batasan/indeks unik pada kunci varchar alami.

Tabel Anda cukup kecil dan kinerjanya dapat dikaitkan dengan klausa OR. Sayangnya, masalah yang sama berlaku tidak peduli bagaimana Anda menyusun kueri (dan saya tidak cukup akrab dengan PostgresSQL untuk menawarkan banyak maaf)

5
gbn

Coba singkirkan bagian "ATAU e2.email IS NULL" dari kueri Anda dan lihat seberapa cepat ia berjalan. Jika berjalan lebih cepat, Anda mungkin dapat menjalankannya lebih cepat dengan "" gabungan semua "

0
Joe Love