O controle de versão de linha aumenta o tamanho dos índices?

Parece que os 14 bytes devem ser adicionados a todos os registros de índice também

Por que ele deve ser adicionado a todos os registros de índice ? Você quer dizer todos os índices ou todas as linhas de todos os índices?

Apenas as linhas afetadas dos índices afetados receberão uma tag de 14 bytes.

Aqui estão 3 exemplos.

Suponha que tenhamos uma tabela agrupada de 100 páginas (com id int PK) e 1 índice não agrupado nela (em outra coluna Col1), e alteramos 10 chaves ( id) de índice agrupado.

Todas as 10 linhas da tabela clusterizada receberão a tag de versão da linha (10 linhas, não 100 linhas), e as 10 linhas afetadas do índice não clusterizado terão essa tag porque cada índice não clusterizado contém a chave do índice clusterizado pelo menos no nível da folha, portanto, 10 linhas de índice não clusterizado terão suas versões também.

Você pode provar isso para si mesmo alterando 10 linhas na tabela clusterizada com índice não clusterizado em db com RCSIe verificando sys.dm_tran_version_store: haverá 20 linhas e você poderá distinguir linhas de índice clusterizadas de linhas de índice não clusterizadas por seu tamanho.

.................................................. .

Agora suponha que temos a mesma tabela com 100 linhas e índice não clusterizado na mesma Col1coluna. Agora fazemos uma coluna updatedeste heap .id

Se você verificar agora sys.dm_tran_version_store, verá apenas 10 linhas, são 10 linhas de um heap, não há nenhuma linha de índice. Isso ocorre porque nosso índice em Col1não foi alterado quando atualizamos 10 id. Nosso id, neste caso, não afeta o índice não clusterizado que possui RID como ponteiro de retorno para um heap no nível da folha.

É claro que se nosso índice não clusterizado tivesse idcomo campo-chave ou campo incluído, updateof idafetaria esse índice também, neste caso, encontramos 20 linhas row version storenovamente.

.................................................. .

Exemplo N3: tabela com estrutura Col1, Col2, Col3. Índices: ix_1 (Col1), ix_3(Col3).

Atualizamos o Col2 que não é apresentado em nenhum índice. Somente as linhas afetadas da tabela receberão tags de versão de linha, ix_1 e ix_3 não serão afetadas.

Como Solomon Rutzky apontou em seu comentário, essas tags de versão serão apresentadas em índices até INDEX REBUILD.

Abaixo está a citação deste livro: Pro SQL Server Internals Por Dmitri Korotkevitch

Níveis de isolamento otimistas contribuem para a fragmentação do índice. Quando uma linha é modificada, o SQL Server aumenta o tamanho da linha em 14 bytes devido ao ponteiro da marca de versão. Se uma página estiver compactada e uma nova versão da linha não couber na página, isso levará a uma divisão de página e fragmentação adicional. Isso é muito semelhante ao padrão de inserção/atualização que discutimos no Capítulo 6, “Fragmentação do índice”. Esses 14 bytes permanecerão na linha, mesmo depois que os registros forem removidos do armazenamento de versão, até que o índice seja reconstruído.

Se forem usados ​​níveis de isolamento otimistas, é recomendável reservar algum espaço nas páginas usando um FILLFACTOR menor que 100. Isso reduz as divisões de página devido a aumentos de tamanho de linha devido aos ponteiros de armazenamento de versão.