Laufzeit von Stored Procedure verkürzen

[Andidreas]

Ja, den haben wir uns angeschaut und der macht das ganze noch unverständlicher.

1. Query über den Ausführungsplan geprüft --> Ergebnis, es wird ein Index vorgeschlagen.
2. Vorgeschlagenen Index angelegt --> Ergebnis, Query minimal schneller.
3. Vorgeschlagenen Index wieder gelöscht und Query erneut über den Ausführungsplan geprüft --> Ergebnis, Es wird kein Index mehr vorgeschlagen!!!

Edit
Nachdem wir den von der MS SQL vorgeschlagenen Index wieder gelöscht haben, sollte doch wieder der fehlende Index vorgeschlagen werden oder sehe ich das falsch?

[Bummi]

Hattet Ihr einen clustered Index erstellt?

[jobo]

Hast Du noch Converts o.ä. Funktionen in den joins? Das ist nicht schön für Indizes. Die gesamte Abfrage sieht sowieso nach FullScan aus, Index hilft da nichts.
Bin kein MSSQL Meister, aber vielleicht gibts da auch sowas wie Statistics Tabellen, die der Query Optimizer zur Berechnung heranzieht. Wenn die nicht passend aktuell sind, kommt Murx raus (kann).

Ein Index würde m.E. Sinn machen, wenn eine zeitabhängige Dimension in der Tabelle und den Abfragen wäre.

[Blup]

Index und Abfrage müssen zusammen passen. Eine Abfrage die für eine Tabelle zugleich mehrere Indexe nutzt, ist in der Regel ineffektiv. Von der Laufzeit ist "In" meist sehr teuer.

Ich würde die Abfrage von Oben im Prinzip so umstellen (hab grad kein MS-SQL):

SQL-Code:

CREATE INDEX IDX_Brand_ProductLine ON [inventory].[dbo].[inventory.inv_test] (ALL_Brand, ALL_ProductLine);

select SUM(PLC_Lower25 * ALL_AvailableStock) as PLC_Lower25,
       SUM(PLC_25 * ALL_AvailableStock) as PLC_25,
       SUM(PLC_30 * ALL_AvailableStock) as PLC_30,
       SUM(PLC_40 * ALL_AvailableStock) as PLC_40,
       SUM(PLC_50_55 * ALL_AvailableStock) as PLC_50_55,
       SUM(PLC_60 * ALL_AvailableStock) as PLC_60,
       SUM(PLC_70 * ALL_AvailableStock) as PLC_70,
       SUM(PLC_TOTAL * ALL_AvailableStock) as PLC_Total
from
      [inventory].[dbo].[fnSplit](@Brand, ';') a,
      [inventory].[dbo].[fnSplit](@Productline, ';') b
left join MyView2 c on (c.ALL_Brand = a.Value) and (c.ALL_ProductLine = b.Value);

Hier wird eine Art Kreuztabelle aus den Werten aus "Brand" und "Produktline" erstellt.
Mit jeder Kombination erfolgt dann jeweils eine Abfrage der eigentlichen Datentabelle.
Durch den Index müssen dabei nur die Datensätze gelesen werden, die der jeweiligen Kombination entsprechen.

Sind nur zwei getrennte Indexe (einer über ALL_BRAND und ein anderer über ALL_ProductLine) vorhanden, ist die Abfrage um ein vielfaches langsamer.

[Andidreas]

Zitat von Bummi:

Hattet Ihr einen clustered Index erstellt?

Nein, sind Clustred Indexe schneller?

Zitat von jobo:

Hast Du noch Converts o.ä. Funktionen in den joins? Das ist nicht schön für Indizes. Die gesamte Abfrage sieht sowieso nach FullScan aus, Index hilft da nichts.

Nein, ich habe mir mittlerweile eine Test Tabelle angelegt in der alle Felder die richtigen Feldtypen haben!

Zitat von Blup:

Sind nur zwei getrennte Indexe (einer über ALL_BRAND und ein anderer über ALL_ProductLine) vorhanden, ist die Abfrage um ein vielfaches langsamer.

Gilt das auch wenn z.B. Index1 und Index2 jeweils die Felder ALL_Brand und ALL_Productline beinhalten?

[Bummi]

Clustered bedeutet dass die Daten physikalisch dem Index entsprechend sortiert werden. Eine Ausführung des Indexoptimierers, nach dem Löschen eines solchen Indexes, kann diesen auf die Idee bringen dass ein weitere Index nicht benötigt würde.

[Andidreas]

Also Clustered Indexe hatten wir noch keine erstellt!

Wir haben aber gerade testweise welche erstellt, aber keine von den getesteten brachte eine Performance Verbesserung.

D.h. die Daten werden immernoch ohne Indexe schneller ermittelt und berrechnet als mit

[Blup]

Zitat:

Zitat von Blup:

Sind nur zwei getrennte Indexe (einer über ALL_BRAND und ein anderer über ALL_ProductLine) vorhanden, ist die Abfrage um ein vielfaches langsamer.

Gilt das auch wenn z.B. Index1 und Index2 jeweils die Felder ALL_Brand und ALL_Productline beinhalten?

Ja, wenn die Abfrage tatsächlich beide Indexe verwendet ist das langsam.
Dazu sieht man sich am besten den Ausführungsplan an.
Es ist nicht nur wichtig das die in der Bedingung verwendeten Felder im enthalten sind, diese sollten auch an erster Stelle im Index definiert sein.

Zitat:

D.h. die Daten werden immernoch ohne Indexe schneller ermittelt und berrechnet als mit

Dann sind entweder die Indexe für die Abfragen nicht geeignet oder die Abfragen ungünstig formuliert.
Bitte mal beides posten.