Frage

Wir verwenden Postgresql v8.2.3.

Es sind Tabellen beteiligt: ANGESTELLTER und Emaillist.

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

2 Tabellen werden so begleitet, dass diese Zeilen zurückgegeben werden, wenn entweder Mitarbeiter oder Mitarbeiter oder Mitarbeiter.Email2 keinen passenden 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 EMAIL welches ist varchar (256) von EMAILLIST Die Tabelle ist indiziert. Jetzt beträgt die Reaktionszeit 14 Sekunden.

Tabellenzählstatistik: Derzeit hat der Mitarbeiter 165.018 Rekorde und Emaillist hat 1.810.228 Rekorde, und beide Tabellen werden voraussichtlich in Zukunft wachsen.

  1. Ist es eine gute Idee/Ansatz, eine Varchar -Spalte zu indexieren? Diese Frage ist mir sofort auf den Sinn, weil wir eine Varchar -Spalte in unserer Anwendung noch nicht indiziert haben. Experten Ratschläge/Vorschlag dazu werden sehr geschätzt.
  2. Mit dieser aktuellen Abfrage und diesem Index ist die Reaktionszeit von 14 Sekunden angemessen oder gibt es einen Umfang zum weiteren Tuning? Was sind die Echtzeiterfahrung/-meinung anderer Benutzer auf dieser Art von Tabellengröße und Reaktionszeit?

HINWEIS: Mein tatsächlicher Anforderungs-/Anwendungsfall wird ausführlich erläutert hier.

War es hilfreich?

Lösung

Es ist nichts Falsches daran, eine Varchar -Spalte zu indizieren, wenn Sie basierend darauf Abfragen machen. Beachten Sie jedoch, dass einige Indizes einschränken und wie viel sie in einem einzelnen Feld indexieren können. Beispiel Sie können keine Spalte indexieren, die eine unbegrenzte Textmenge enthalten kann. Sie sollten jedoch in der Lage sein, einen Index für VARCHAR (256) ohne Probleme durchzuführen. Probieren Sie es aus und analysieren Sie die Verbesserungen in Ihrer Abfrageleistung, um festzustellen, ob es hilft.

Andere Tipps

Es gibt keine Probleme mit der Indexierung einer Varchar -Spalte als solche

Wo es zu einem Problem werden kann, ist, wenn Sie die Varchar -Spalte als FK in einer Milliarde Zeilentabelle haben. Sie würden dann einen Ersatzschlüssel für PK und FK haben, aber Sie benötigen immer noch eine eindeutige Einschränkung/einen Index für den natürlichen Varchar -Schlüssel.

Ihre Tische sind ziemlich klein und die Leistung kann mit der oder Klausel zusammenhängen. Leider gilt das gleiche Problem, egal wie Sie die Abfrage strukturieren (und ich bin mit Postgressql nicht vertraut, um viel leid zu bieten).

Versuchen Sie, den Teil Ihrer Abfrage "oder e2. EMICIA Is NULL" loszuwerden, und sehen Sie, wie schnell er läuft. Wenn es schneller läuft, können Sie es möglicherweise schneller mit einer "Gewerkschaft All" ausführen

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit dba.stackexchange
scroll top