By Frank Kalis
Von Zeit zu Zeit kann die Neuerstellung eines Clustered Index signifikante Performancesteigerung bewirken. Doch was passiert eigentlich während solch einer Operation?...
Viele Quellen im Internet behaupten, daß während der Neuerstellung eines Clustered Index sämtliche Nonclustered Indexes derselben Tabelle automatisch neu erstellt werden. Dies ist leider nur teilweise richtig. Uneingeschränkt richtig ist dieses Verhalten für SQL Server 2000 Service Pack 1 und früher. Mit Service Pack 2 (SP2) hat sich aber dies geändert. Nun entscheidet die "Art", wie der Clustered Index erstellt wurde, ob Nonclustered Indexes ebenfalls neu erstellt werden müssen oder nicht.
Ein Clustered Index kann als UNIQUE Index erstellt werden oder nicht. Läßt man das Keywort UNIQUE weg, fügt SQL Server automatisch einen 4-byte Uniqueifier zu den entsprechenden Schlüsseln hinzu, wenn ein Duplikat entdeckt wird. Auf diesem Weg ist sichergestellt, das intern einmalige Werte vorliegen. Wird nun der Clustered Index neu erstellt, wird auch der Uniqueifier neu generiert. Da die Clustered Index Schlüssel den Bookmark der Nonclustered Indexes bilden, müssen diese zwangsläufig ebenfalls neu generiert werden.
Anders verhält es sich bei einem Clustered Index der als UNIQUE erstellt wurde. Hier gibt es keinen künstlichen Uniqueifier, sondern nur die Clustered Index Schlüssel. Da sich diese nicht während einer Neuerstellung ändern, braucht auch keiner der Nonclustered Indexes neu erstellt zu werden.
Was bedeutet dies nun für die Praxis?
Nun, es sollte direkt einleuchten, das die Neuerstellung eines als UNIQUE erstellten Clustered Index deutlich schneller ist, da weniger zusätzliche Arbeit verrichtet werden muß. Und wenn die Chance besteht, einen Clustered Index als UNIQUE zu erstellen, sollte man dies nutzen. Falls keine Möglichkeit besteht, den Index zu verändert, sollte man vielleicht eine Umstellung von ALTER INDEX ... REBUILD auf ALTER INDEX ... REORGANIZE ins Auge fassen.