Det finns få prestandaimplikationer, rowversion är bara ett nytt namn för den gamla tidsstämpeldatatypen. Så din databas kommer att behöva lagra det extra binära fältet. Din prestation kommer att lida mycket mer när du försöker göra frågor om denna data som:
SELECT *
FROM MyTable
WHERE rowVersion > @rowVersion
Vilket är det vanliga sättet som kan användas för att få listan över uppdaterade objekt sedan senaste @rowVersion. Det här ser bra ut och kommer att fungera perfekt för en tabell med säg 10 000 rader. Men när du kommer till 1M rader kommer du snabbt att upptäcka att den alltid har gjort en tabellskanning och din prestationsträff beror på att din tabell nu inte längre passar helt i serverns RAM.
Detta är det vanliga problemet som uppstår med rowVersion kolumn, är det inte magiskt indexerat på egen hand. Dessutom, när du indexerar en rowVersion-kolumn måste du acceptera att indexet ofta blir väldigt fragmenterat med tiden, eftersom de nya uppdaterade värdena alltid kommer att vara längst ner i indexet, vilket lämnar luckor genom hela indexet när du uppdaterar befintliga objekt .
Redigera:Om du inte ska använda rowVersion fältet för att söka efter uppdaterade objekt och istället kommer du att använda det för konsekvens för att säkerställa att posten inte uppdateras sedan du senast läste, då kommer detta att vara en helt acceptabel användning och kommer inte att påverka.
UPDATE MyTable SET MyField = ' @myField
WHERE Key = @key AND rowVersion = @rowVersion