Używamy PostgreSQL v8.2.3.
W grę wchodzą tabele: PRACOWNICY 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 EMAILktóry VARCHAR (256) z EMAILLISTtabeli jest indeksowany. 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 wzrosną w przyszłości.
- Czy dobrym pomysłem / podejściem jest indeksowanie 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. Bardzo cenne są porady / sugestie ekspertów.
- Przy obecnym zapytaniu i indeksie czas odpowiedzi wynoszący 14 sekund jest rozsądny, czy jest też miejsce na dalsze dostrajanie? Jakie są wrażenia / opinie innych użytkowników w czasie rzeczywistym w oparciu o ten rozmiar tabeli i czas reakcji?
UWAGA: Moje rzeczywiste zapotrzebowanie / przypadek użycia jest szczegółowo wyjaśniony tutaj .
performance
postgresql
index
query
Gnanam
źródło
źródło
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ć związana z klauzulą OR. Niestety ten sam problem obowiązuje bez względu na strukturę zapytania (i nie znam wystarczająco dużo PostgresSQL, aby zaoferować dużo przepraszam)
źródło
Spróbuj pozbyć się części zapytania „OR e2.email IS NULL” i sprawdź, jak szybko działa. Jeśli działa szybciej, być może będziesz w stanie uruchomić go szybciej dzięki „union all”
źródło