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?
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
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". –
@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). –