Announcement

Collapse
No announcement yet.

Geschwindigkeitsverbesserung bei String-Vergleich im JOIN über große Tabelle gesucht

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Geschwindigkeitsverbesserung bei String-Vergleich im JOIN über große Tabelle gesucht

    hallo,
    ich lasse mir täglich von mehreren Active Directorys Benutzer, Gruppen und Gruppenmitgliedschaften in eine MSSQL-Tabelle schreiben. Als eindeutiges Kennzeichen von Benutzer und Gruppen verwende ich die GUIDs aus der AD, das speichere ich als varchar(100).

    Ich möchte die Änderungen in der Gruppenmitgliedschaft ermitteln. Also welcher Benutzer hat welche Gruppe neu dazu bekommen und welcher Benutzer hat welche Gruppe entfernt bekommen. Dazu vergleiche ich immer zwei Tage von Imports über ein LEFT JOIN wo der eine JOIN-Teil dann NULL ist. So finde ich das Ergebnis. Damit mein JOIN funktioniert setze ich die GUIDs gleich. Alles prima, funktioniert prinzipiell, ich erhalte das Ergebnis. Wenn ich das nun auf dem Live-SQL-Server ausführe klagen die Benutzer darüber dass in anderen Anwendungen der SQL-Server nicht mehr antwortet. Ich kann das auch schön nachvollziehen dass er extrem auf der Festplatte rumliest wenn ich die Ergebnisse rechnen lasse.

    Jetzt interessiert mich wie ich das so hinbekomme dass die Benutzer noch arbeiten können. Ich vermute das Problem an den langen "Textschlüsseln". Es sind keine echten Schlüssel, also ich habe keine Primärschlüssel auf die GUIDs gesetzt (kann ich auch aktuell nicht da ich die GUIDs mehrfach, einmal pro Tag in der Gruppen-Tabelle bzw. Benutzer-Tabelle habe. Grund: damit ich in anderer Auswertung auch noch die Namensänderungen, Heirat o.ä. bestimmen kann.).

    Mir fällt nichts mehr gescheites ein. Nur noch dass ich eine "Übersetzungstabelle" von GUID auf bigint machen könnte und dann die Mitgliedschaften ebenfalls in bigint übersetze um dann beim JOIN hoffentlich schneller zu sein. Aber selbst da bin ich mir nicht so sicher ob das fruchtet.

  • #2
    Du kannst die Spalte auch einfach Indexieren (ohne Unique Anforderung). Aber warum sind die GUIDs varchars? Speichere die als UniqueIdentifier. Dann sind es wirklich 128bit Zahlenwerte die sich deutlich schneller vergleichen lassen sollten.

    Comment


    • #3
      hallo, hab jetzt die varchars zu uniqueidentifier gemacht. Mir war nicht klar dass es tatsächlich der Datentyp ist, dachte es sind andere Strings. Im testsystem ging das alleine schon schneller. Im Livesystem ist es immer noch etwas träge. Kann aber auch daran liegen dass mehr in den Tabellen ist. Evtl. setze ich noch einen Index. Danke für deine Hilfe.

      Comment

      Working...
      X