Hallo MichaelS, legt nur meine Variante den Server lahm? Oder deine auch? Ich habe mir eine Weile Gedanken gemacht, ob man die Query besser gestalten könnte. Deine IFs gefallen mir nicht wirklich. Aber die Alternativen, die ich gefunden hatte, machen 3 Joins statt einen, und das ist vermutlich noch weniger effizient. Bei Performanceproblemen lautet die erste Anlaufstelle immer EXPLAIN, und dann muss man schauen, welchen Ausführungsplan er für die Query wählt. Die Größe der Kundentabelle ist egal, die ist an der Query nicht beteiligt. 50K Kontakte bei 117 Kontaktarten sind natürlich schon eine Menge, das sind potenziell 5 Millionen Kombinationen. Ohne Kenntnis des Explain hätte ich folgende notorische Kandidaten für Langsamkeit: Wenn die Spalte Kontaktart.Kontaktart keinen Index hat, muss der Server pro Eintrag in Kontakte einen Tablescan auf Kontaktart machen. Mit Index wäre es ein Index-Seek. Um einen Vorschlag für einen optimalen Index machen zu können, müsstest Du mal die Table-Definition herzeigen (Spalten, Primary Key, existierende Indexe). Ist Kontakte.KuIndex erster Teil des Primary Key von Kontakte? Hat der Primary Key einen Clustering-Index? Wenn nicht, kostet auch der group by viel Zeit weil er dann sortieren muss. _Rolf_ -- sumpsi - posui - clusi

Hallo MichaelS, legt nur meine Variante den Server lahm? Oder deine auch? Die Kundentabelle ist egal, die ist an der Query nicht beteiligt. Bei Performanceproblemen lautet die erste Anlaufstelle immer EXPLAIN, und dann muss man schauen, welchen Ausführungsplan er für die Query wählt. Ohne Kenntnis des Explain hätte ich folgende notorische Kandidaten für Langsamkeit: Wenn die Spalte Kontaktart.Kontaktart keinen Index hat, muss der Server pro Eintrag in Kontakte einen Tablescan auf Kontaktart machen. Ist Kontakte.KuIndex Teil des Primary Key von Kontakte? Hat der Primary Key einen Clustering-Index? Wenn nicht, kostet auch der group by viel Zeit weil er dann sortieren muss. _Rolf_ -- sumpsi - posui - clusi