2016-05-29 1 views
0

Ich habe eine Tabelle mit 7 Spalten:SQL Server schlug einen Index vor, der im Grunde alle Spalten aus der Tabelle hat - ist das eine gute Idee?

  • ProductId
  • WarehouseId
  • StockDate
  • OnHandQuantity
  • InTransitQuantity
  • ErstellDat
  • AngelegtVon

Einer meiner Benutzer versucht, die Leistung einer Abfrage zu verbessern, und hat einen Index erstellt, der von SSMS vorgeschlagen wurde. Der Index sieht wie folgt aus:

CREATE NONCLUSTERED INDEX [IDX1_FactStock2016] ON [dbo].[FactStock2016] 
(
    [WarehouseId] ASC 
) 
INCLUDE ([ProductId],[StockDate],[OnHandQuantity],[InTransitQuantity]) 

mir jetzt, es unlogisch scheint einen Index wie diese zu erstellen, wenn es umfasst grundsätzlich alle Spalten aus der zugrundeliegenden Tabelle (ErstellDat und AngelegtVon sind nicht relevant). Erstellt das im Grunde nicht eine Kopie der Tabelle als einen Index (minus die zwei Audit-Spalten)? Wird dies tatsächlich Auswirkungen auf die Geschwindigkeit haben?

Antwort

1

Ein solcher Index wäre ein Deckungsindex für alle Abfragen in der Tabelle. Bei vielen Abfragen könnte dies der beste Index sein.

Es gibt andere Optionen, z. B. einen gruppierten Index, der WarehouseId als den ersten Schlüssel im Index hat.

Ob dies eine gute Idee ist oder nicht, hängt von Ihrer Umgebung ab. Wenn Ihr einziges Anliegen die Durchführung der Abfrage dieses einen Benutzers ist, dann klingt das nach einer guten Idee. Zusätzliche Indizes verursachen zusätzlichen Aufwand für Einfügungen, Aktualisierungen und Löschungen (obwohl Indizes je nach Bedingungen auch die Ausführung von Aktualisierungen unterstützen und löschen können). Das Hinzufügen weiterer Indizes erfordert eine Abwägung von Überlegungen. Es gibt nichts a priori falsch, obwohl über Indizes für eine Abfrage abdecken.

+0

Warum sollte also ein überdeckender Index, der im Grunde ALLE Spalten der zugrundeliegenden Tabelle enthält (und nicht nur um die Abfrage zu erfüllen), effektiver sein, als die Tabelle selbst abzufragen? – Lock

+0

Wenn die Schlüsselabfragen in den Clustered-Index zurückfallen würden, wäre dies ausreichend kostspielig, da der deckende, nicht geclusterte Index die Kosten wert ist. Zwei Szenarien, bei denen ich denken kann, wo das von Kopf bis Fuß passieren würde. 1) der CE unterschätzt, wie viele Zeilen zurückkommen werden und somit unterschätzt, wie oft die Schlüsselsuche durchgeführt wird. 2) wenn genug Reihen zurückkommen, wo das CE sagt "nah ... es ist effizienter, den gruppierten Index zu verwenden, obwohl Sie diesen nicht-deckenden nicht-gruppierten Index haben". –

+0

@Lock. . . Wegen anderer Bedingungen in der Abfrage. Der Index könnte für "where" - oder "order by" -Bedingungen verwendet werden (oder sogar um "group by" zu erleichtern). –

1

Ja, ein Deckungsindex wie dieser ist eine redundante Kopie der Daten. Er kann auch die Abfrageleistung verbessern, indem die Schlüsselsuche vermieden wird.

Indexierungsentscheidungen beinhalten oft Kompromisse. Bewerten Sie, ob die zusätzlichen Kosten für Lagerung und Wartung die Leistungsgewinne überwiegen. Eine häufig ausgeführte Abfrage, die vom Index profitiert, kann die Kosten sehr wohl überwiegen.

0

Dieser Index Vorschlag bedeutet im Grunde, dass, für diese bestimmte Abfrage, wäre es besser, wenn Tabelle Cluster-Index wäre auf der WarehouseId Spalte gebaut worden. Da Sie nicht mehr als 1 Clustered-Index für eine bestimmte Tabelle oder View haben können, manchmal kann dieser Überschuss den zusätzlichen Speicherplatz (und einige zusätzliche Leistungseinbußen von Datenmodifikationsanweisungen) wert sein.

Ob es vorteilhaft ist oder nicht, Sie können jedoch nur für sich selbst und Ihr System entscheiden - es gibt keine allgemeinen Empfehlungen in dieser Angelegenheit, die zu jeder Situation außer SQL Server Indexnutzungsstatistiken passen würden und was Sie daraus erhalten können . Suchen Sie nach Indexvorschlagsskripten, es gibt viele davon überall.

+0

Ah hast du. Das ist die Art von Antwort, die ich suchte. Wenn also mein gruppierter Schlüssel zuerst ein Lager hatte (es ist eigentlich ein zusammengesetzter Schlüssel mit zwei anderen Feldern), hätte er diesen Index nicht vorgeschlagen? – Lock

+0

@Lock, vielleicht. Es gibt einige allgemeine Empfehlungen zur Auswahl eines Clustered-Index, die besser zu folgen sind, normalerweise (so eng wie möglich, vorzugsweise einzigartig usw.). Vergessen Sie nicht, dass andere Abfragen, die auf diese Tabelle zugreifen, ebenfalls betroffen sind, wenn Sie Ihren vorhandenen Clustered-Index ändern, um diese Abfrage zu optimieren. Und die Veränderung wird nicht unbedingt gut für sie sein. Ja, es ist ein ziemlich heikler Prozess des Ausgleichs, um kurz zu sein. –