it-swarm.dev

Czy to dobry pomysł / podejście do indeksowania kolumny VARCHAR?

Używamy PostgreSQL v8.2.3.

W grę wchodzą tabele: [~ # ~] pracownik [~ # ~] i [~ # ~] emaillist [~ # ~] .

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

2 tabele są połączone w taki sposób, że jeśli EMPLOYEE.EMAIL1 lub EMPLOYEE.EMAIL2 nie mają pasującego wpisu, wiersze te zostaną zwrócone.

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

Kolumna EMAIL, która jest varchar (256) tabeli EMAILLIST jest indeksowana. Teraz czas reakcji wynosi 14 sekund.

Statystyka liczby tabel: obecnie EMPLOYEE ma 165 018 rekordów, a EMAILLIST ma 1810 228 rekordów, i oczekuje się, że obie tabele będą w przyszłości rosły.

  1. Czy to dobry pomysł/podejście do indeksowania kolumny VARCHAR? To pytanie od razu przyszło mi do głowy z tego powodu, że nie zaindeksowaliśmy kolumny VARCHAR wcześniej w naszej aplikacji. Rady ekspertów/sugestie na ten temat są bardzo mile widziane.
  2. Przy obecnym zapytaniu i indeksie czas odpowiedzi wynoszący 14 sekund jest rozsądny, czy jest też miejsce na dalsze dostrajanie? Jakie są doświadczenia/opinie innych użytkowników w czasie rzeczywistym oparte na tego rodzaju rozmiarze stołu i czasie reakcji?

UWAGA: Mój faktyczny przypadek zapotrzebowania/użycia jest szczegółowo wyjaśniony tutaj .

33
Gnanam

Nie ma nic złego w indeksowaniu kolumny varchar, jeśli zamierzasz wykonywać na niej zapytania. Należy jednak pamiętać, że niektóre indeksy mają ograniczenia i ile mogą indeksować w jednym polu. Przykład: nie można zaindeksować kolumny, która może zawierać nieograniczoną ilość tekstu. Jednak powinieneś być w stanie zrobić indeks na varchar (256) bez problemu. Wypróbuj i przeanalizuj poprawę wydajności zapytań, aby sprawdzić, czy to pomoże.

26
xenoterracide

Nie ma problemu z indeksowaniem kolumny varchar jako takiej

Problemem może być sytuacja, gdy kolumna varchar ma postać FK w tabeli o miliardach wierszy. Miałbyś wtedy klucz zastępczy dla PK i FK, ale nadal potrzebujesz unikalnego ograniczenia/indeksu dla naturalnego klucza varchar.

Twoje tabele są dość małe, a wydajność może być powiązana z klauzulą ​​OR. Niestety ten sam problem dotyczy bez względu na strukturę zapytania (i nie jestem wystarczająco zaznajomiony z PostgresSQL do zaoferowania) bardzo przepraszam)

5
gbn

Spróbuj pozbyć się części zapytania „OR e2.email IS NULL”) i przekonaj się, jak szybko działa. Jeśli działa szybciej, być może będziesz w stanie uruchomić go szybciej dzięki „unii wszystkie „

0
Joe Love