Tabelle performanter macher

[MysterioJN]

Moin zusammen,

könnt ihr mir ein paar kleine Tips bzgl. Performance bei MSSQL-Tabellen (verwaltete über das Management Studio) geben?

In unserem Intranet verwende ich sehr viele Selects auf Datenbanken im Haus. Das Problem, sobald es die Absatz/Umsatztabelle betrifft, die etwas mehr als 2,8 Millionen Datenzeilen hat, das System in die "Knie" geht,
bzw. Abfragen recht lange brauchen bis das Ergebnis geliefert wird.

Der Ausführungsplan sagt mir im Prinzip immer, das die meiste Ressource in % (teilweise über 90%!) mit dem "Index Scan (Non Clustered" auf die Bestellnummer verwendet wird.

Wenn ich jetzt einen INDEX auf wichtige Spalten in dieser besagten Tabelle mache, wie sollte der aussehen?

Bei Create INDEX on... kommt hinterher "nicht eindeutig, nicht gruppiert" dabei heraus.
Was bedeutet das letztendlich?

Was sagen mir "Statistiken" und wieso legen die sich automatisch an?

Mir ist bewusst, das es sich hierbei um ein eigenständiges Aufgabengebiet der Performance handelt, aber vlt. ist es auch ein Grundlagentip der mir weiterhelfen kann.

Wie immer, beste Grüße und danke fürs Lesen!

 

[akretschmer]

Wenn ich jetzt einen INDEX auf wichtige Spalten in dieser besagten Tabelle mache, wie sollte der aussehen?

Indexe legt man prinzipiell auf die Spalten, die in der WHERE-Condition auftauchen oder beim ORDER BY. Ist Bestellnummer Teil des WHERE? Wenn Du mehrere Spalten im WHERE hast kann es sehr nützlich sein, einen kombnierten Index über diese Spalten anzulegen.

 

[MysterioJN]

Ja, diese Tabelle hat ca. 6 Spalten die ich immer wieder als WHERE aufrufe.

Kurze Abfragebeispiele (damit du mir besser den Kombinierten Index erklären kannst):
- nach (bestimmten) Artikelnummern
- und/oder nach (bestimmten) Kundennummern
- und/oder nach (bestimmten) Kundenbranchen_IDs
- und/oder nach (bestimmten) Aktions_IDs

Problem, nicht IMMER brauch ich alle Spalten, bzw. nicht IMMER stehen alle Spalten als WHERE.

Klappt das denn dann mit einem kombinierten index wenn nicht immer die Zusammengehörigkeit gefragt ist?
Wenn ja, hast du ein Beispiel wie ich das anlege / wie er aussehen müsste?

Entschuldige, aber da bin ich wirklich noch sehr unerfahren was das angeht - aber ich glaube, es ist der Schlüssel zu meinem enormen Performanceproblem.

 

[akretschmer]

Klappt das denn dann mit einem kombinierten index wenn nicht immer die Zusammengehörigkeit gefragt ist?

Jein. Wenn der Index auf (col1, col2, col3) ist und im Where steht: col1=10 and col2=20, dann klappt es. Steht im Where aber: col2=20 and col3=50 dann nicht. Also, die ersten Spalten im Index müssen auch im Where vorkommen.

Wenn das so ist wie Du schilderst und Du hättest PostgreSQL, dann könntest Du aber auch je Spalte einen einfachen Index setzen und je nach dem, was im Where vorkommt, würde PG dann einen 'Bitmap Index Scan' machen: dabei nutzt er die Indexe, sofern da, erstellt im Speicher eine Bitmap über die einzelnen Treffer der indexe und schaut, wo in der Bitmap alle Indexe eine '1' liefern. Das geht in PG seit vielleicht 10 Jahren und ist ziemlich cool ...

 

[ukulele]

Man könnte aber auch einen zweiten Index (col2,col3) anlegen. Die Indexe verlangsammen natürlich die Schreiboperationen, also macht das nur Sinn wenn es nötig ist.