Es gibt nur wenige Auswirkungen auf die Leistung, rowversion ist nur ein neuer Name für den alten timestamp-Datentyp. Ihre Datenbank muss also das zusätzliche Binärfeld speichern. Ihre Leistung wird viel mehr leiden, wenn Sie versuchen, Abfragen für diese Daten durchzuführen, wie zum Beispiel:
SELECT *
FROM MyTable
WHERE rowVersion > @rowVersion
Dies ist der übliche Weg, um die Liste der aktualisierten Elemente seit der letzten @rowVersion abzurufen. Dies sieht gut aus und funktioniert perfekt für eine Tabelle mit beispielsweise 10.000 Zeilen. Aber wenn Sie 1 Mio. Zeilen erreichen, werden Sie schnell feststellen, dass es immer einen Tabellenscan durchgeführt hat und Ihr Leistungseinbruch darauf zurückzuführen ist, dass Ihre Tabelle jetzt nicht mehr vollständig in den Arbeitsspeicher des Servers passt.
Dies ist das allgemeine Problem, das bei rowVersion auftritt Spalte, wird es nicht magisch selbst indiziert. Wenn Sie eine rowVersion-Spalte indizieren, müssen Sie außerdem akzeptieren, dass der Index im Laufe der Zeit oft sehr fragmentiert wird, da die neuen aktualisierten Werte immer am Ende des Index stehen und Lücken im gesamten Index hinterlassen, wenn Sie vorhandene Elemente aktualisieren .
Bearbeiten:Wenn Sie nicht gehen, verwenden Sie die rowVersion Feld für die Suche nach aktualisierten Elementen verwenden und es stattdessen aus Gründen der Konsistenz verwenden, um sicherzustellen, dass der Datensatz seit dem letzten Lesen nicht aktualisiert wurde, dann ist dies eine vollkommen akzeptable Verwendung und hat keine Auswirkungen.
UPDATE MyTable SET MyField = ' @myField
WHERE Key = @key AND rowVersion = @rowVersion
