it-swarm-eu.dev

Ist es eine gute Idee / ein guter Ansatz, eine VARCHAR-Spalte zu indizieren?

Wir verwenden PostgreSQL v8.2.3.

Es sind Tabellen beteiligt: ​​ [~ # ~] Mitarbeiter [~ # ~] und [~ # ~] Emaillist [~ # ~].

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

2 Tabellen werden so verknüpft, dass diese Zeilen zurückgegeben werden, wenn entweder EMPLOYEE.EMAIL1 oder EMPLOYEE.EMAIL2 keinen übereinstimmenden Eintrag haben.

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

Die Spalte EMAIL, die varchar (256) der Tabelle EMAILLIST ist, wird indiziert. Jetzt beträgt die Antwortzeit 14 Sekunden.

Statistik der Tabellenanzahl: Derzeit verfügt EMPLOYEE über 165.018 Datensätze und EMAILLIST über 1.810.228 Datensätze. Beide Tabellen werden voraussichtlich in Zukunft wachsen.

  1. Ist es eine gute Idee/ein guter Ansatz, eine VARCHAR-Spalte zu indizieren? Diese Frage fällt mir sofort ein, weil wir in unserer Anwendung noch keine VARCHAR-Spalte indiziert haben. Experten Ratschläge/Vorschläge hierzu werden sehr geschätzt.
  2. Bei dieser aktuellen Abfrage und diesem aktuellen Index ist die Antwortzeit von 14 Sekunden angemessen oder gibt es Raum für weitere Optimierungen? Welche Erfahrungen/Meinungen anderer Benutzer in Echtzeit basieren auf dieser Art von Tabellengröße und Antwortzeit?

HINWEIS: Mein tatsächlicher Bedarf/Anwendungsfall wird ausführlich erklärt hier .

33
Gnanam

Es ist nichts Falsches daran, eine varchar-Spalte zu indizieren, wenn Sie darauf basierende Abfragen durchführen. Beachten Sie jedoch, dass einige Indizes begrenzt sind und wie viel sie in einem einzelnen Feld indizieren können. Beispiel: Sie können keine Spalte indizieren, die eine unbegrenzte Textmenge enthalten kann. Sie sollten jedoch in der Lage sein, einen Index für varchar (256) ohne Probleme zu erstellen. Probieren Sie es aus und analysieren Sie die Verbesserungen der Leistung Ihrer Abfragen, um festzustellen, ob dies hilfreich ist.

26
xenoterracide

Es gibt kein Problem beim Indizieren einer Varchar-Spalte als solche

Es kann zu einem Problem werden, wenn Sie die varchar-Spalte als FK in einer Milliardenzeilentabelle haben. Sie hätten dann einen Ersatzschlüssel für PK und FK, benötigen jedoch noch eine eindeutige Einschränkung/einen eindeutigen Index für den natürlichen Varchar-Schlüssel.

Ihre Tabellen sind recht klein und die Leistung könnte mit der Klausel OR] zusammenhängen. Leider gilt das gleiche Problem, unabhängig davon, wie Sie die Abfrage strukturieren (und ich bin mit PostgresSQL nicht vertraut genug, um es anzubieten sehr leid)

5
gbn

Versuchen Sie, den Teil "OR e2.email IS NULL") Ihrer Abfrage zu entfernen, und sehen Sie, wie schnell er ausgeführt wird. Wenn er schneller ausgeführt wird, können Sie ihn möglicherweise mit einer "union all" schneller ausführen ""

0
Joe Love