Warum SQL server Tuning Advisor schlägt vor, PRIMARY KEY zu den enthaltenen Spalten des Index hinzuzufügen?

Ich habe dies eine Reihe von timeen gesehen, wenn ich einige Analysen in SQL server DataBase Engine Tuning Advisor ausführen, schlägt mir vor, Indizes wie:

CREATE NONCLUSTERED INDEX [_index] ON [dbo].[SomeTable] ( [Column1] ASC, [Column2] ASC, [Column3] ASC ) INCLUDE ([PrimaryKeyColumn]) 

Ist es wirklich wichtig, die Primärschlüssel (gruppierten Index) Spalte in die enthaltene Spaltenliste aufzunehmen? Ich denke immer, dass es standardmäßig als Link zur ursprünglichen Zeile enthalten ist. Liege ich falsch?

Update: Ich denke, es ist auch wichtig zu beachten, dass es einen solchen Index für Abfrage wie folgt vorschlägt: SELECT [PrimaryKeyColumn] FROM [dbo] [SomeTable] WHERE … [Bedingungen] … und es beeinflusst wirklich performance und Ausführungsplan. Also so weit ich verstehe, Index enthält nicht wirklich 'gruppierten Index', sondern nur einige Link zu Zeile. Ist es so?

Sie können den Index mit oder ohne INCLUDE erstellen: SQL server ignoriert es, wenn der PrimaryKeyCol der gruppierte Index ist. Das heißt, es wird den geclusterten Indexwert nicht zweimal speichern

Für Vollständigkeit würde ich wahrscheinlich für den Fall, dass ich jemals den gruppierten Index ändere

Bearbeiten:

Ich habe über die Größe beobachtet, die SQL server damit intelligent behandelt
Dies ist nicht so wissenschaftlich wie Kalen Delaney mehr über Nonclustered Index Keys

 DROP TABLE IncludeTest; GO CREATE TABLE IncludeTest ( BadClusteredKey uniqueidentifier DEFAULT NEWID() PRIMARY KEY, OtherCol AS CHECKSUM(BadClusteredKey) % 10000, Filler char(200) NOT NULL DEFAULT 'a and lots of spaces' ); GO INSERT IncludeTest (Filler) VALUES (DEFAULT); GO INSERT IncludeTest (Filler) SELECT Filler FROM IncludeTest GO 20 SELECT COUNT(*) FROM IncludeTest; EXEC sp_spaceused 'IncludeTest', 'true' GO -- 400680 KB, 1920 KB CREATE INDEX IX_OtherCol1 ON IncludeTest (OtherCol); GO EXEC sp_spaceused 'IncludeTest', 'true' GO -- 400680 KB, 29024 KB KB DROP INDEX IncludeTest.IX_OtherCol1 GO EXEC sp_spaceused 'IncludeTest', 'true' GO -- 400680 KB, 1920 KB CREATE INDEX IX_OtherCol2 ON IncludeTest (OtherCol) INCLUDE (BadClusteredKey); EXEC sp_spaceused 'IncludeTest', 'true' GO -- 400680 KB, 29024 KB DROP INDEX IncludeTest.IX_OtherCol2 GO EXEC sp_spaceused 'IncludeTest', 'true' GO -- 400680 KB, 1920 KB 

Ich denke, Tuning Advisor erkennt Sie Abfrage und festgestellt, dass Sie PrimaryKeyColumn in Ihnen wählen Ursache und Sie haben Column1, Column2 und Column3 in wo Ursache.

Tuning Advisor denken, dass …. wenn Sie Index enthalten PrimaryKeyColumn in den Index SQL nicht brauchen, um Overhead zu suchen, um zu sehen, PrimaryKeyColumn data in data-Seite (Tabelle data-Seite). SQL-Engine wäre in der Lage, PrimaryKeyColumn Wert aus Index direkt für Sie Abfrage zu nehmen. es spart time

Beachten Sie, dass: Es gibt eine schlechte Seite des Index (Spalte enthalten). unter http://msdn.microsoft.com/en-us/library/ms190806.aspx enthält nützliche Informationen, die Ihnen helfen könnten, eine Entscheidung zu treffen.