Ist es eine gute Idee, eine VARCHAR-Spalte zu indizieren?


32

Wir verwenden PostgreSQL v8.2.3.

Es handelt sich um Tabellen: EMPLOYEE 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

Spalte , EMAILdie ist varchar (256) die EMAILLISTTabelle ist indiziert. Die Reaktionszeit beträgt jetzt 14 Sekunden.

Statistik der Tabellenzahl: Derzeit hat EMPLOYEE 165.018 Datensätze und EMAILLIST 1.810.228 Datensätze, und beide Tabellen werden voraussichtlich in Zukunft wachsen.

  1. Ist es eine gute Idee, eine VARCHAR-Spalte zu indizieren? Diese Frage ist mir sofort in den Sinn gekommen, weil wir in unserer Anwendung noch keine VARCHAR-Spalte indiziert haben. Expertenratschläge / -vorschläge hierzu werden sehr geschätzt.
  2. Bei dieser aktuellen Abfrage und diesem Index ist die Antwortzeit von 14 Sekunden angemessen oder gibt es einen Spielraum für weitere Optimierungen? Welche Echtzeiterfahrungen / Meinungen anderer Benutzer basieren auf dieser Art von Tabellengröße und Antwortzeit?

HINWEIS: Meine tatsächlichen Anforderungen / Anwendungsfälle werden hier ausführlich erläutert .

Antworten:


25

Es ist nichts Falsches daran, eine varchar-Spalte zu indizieren, wenn Sie darauf basierende Abfragen durchführen. Beachten Sie jedoch, dass einige Indizes Beschränkungen unterliegen und wie viel sie in einem einzelnen Feld indizieren können. Beispiel Sie können keine Spalte indizieren, die eine unbegrenzte Menge an Text 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 Abfrageleistung, um festzustellen, ob dies hilfreich ist.


Vielen Dank für Ihren wertvollen Kommentar. Kann ich meine Anfrage in dieser Hinsicht weiter optimieren, um die Antwortzeit von 14 Sekunden zu verkürzen?
Gnanam

2
Ohne die Ergebnisse von EXPLAIN ist es unmöglich zu sagen, was optimiert werden soll. Version 8.2.3 ist ebenfalls veraltet. Sie sollten ein Upgrade auf eine neuere Version durchführen, da Sie 4 Jahre hinter der Wartung zurückliegen. Die Versionen 8.3, 8.4 und 9.0 sind in vielen Situationen auch schneller. Bessere Statistiken tragen auch zur Leistungssteigerung bei.
Frank Heikens

5

Die Indizierung einer varchar-Spalte als solche ist problemlos möglich

Wenn Sie die varchar-Spalte als FK in einer Milliarde-Zeilen-Tabelle haben, kann dies zu einem Problem werden. Sie hätten dann einen Ersatzschlüssel für die PK und die FK, aber Sie würden immer noch eine eindeutige Einschränkung / einen eindeutigen Index für den natürlichen varchar-Schlüssel benötigen.

Ihre Tabellen sind recht klein und die Leistung kann mit der OR-Klausel zusammenhängen. Leider gilt das gleiche Problem, unabhängig davon, wie Sie die Abfrage strukturieren (und ich kenne mich mit PostgresSQL nicht gut genug aus, um viel zu tun zu haben).


0

Versuchen Sie, den Teil "OR e2.email IS NULL" Ihrer Abfrage zu entfernen und festzustellen, wie schnell die Abfrage ausgeführt wird. Wenn es schneller läuft, können Sie es möglicherweise mit einem "union all" schneller ausführen.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.