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 .