Ryan's questions

Usando o servidor SQL, se eu navegar para uma tabela no explorador de objetos, vá para seus índices, vá para suas propriedades e visualize a guia de fragmentação, a seção superior tem 2 linhas para mim, o preenchimento da página em porcentagem e a fragmentação total em porcentagem.

Também tenho uma consulta que uso ocasionalmente para obter informações de índice. Cortando alguns campos não relacionados, esta é a consulta:

SELECT t.name, ix.name, avg_fragmentation_in_percent
FROM sys.indexes AS ix
INNER JOIN sys.tables t ON t.object_id = ix.object_id
INNER JOIN sys.schemas s ON t.schema_id = s.schema_id
INNER JOIN sys.dm_db_index_physical_stats  (db_id(), NULL, NULL, NULL, 'DETAILED') ps ON t.object_id = ps.object_id AND ix.index_id = ps.index_id
WHERE  ix.index_id > 0
    AND ix.name IS NOT NULL

Quando executo esta consulta, obtenho 3 colunas, as 2 primeiras apontando para o próprio índice e, para esta consulta, a terceira é uma fragmentação em porcentagem para esse índice.

Esses 2 números geralmente são muito próximos, às vezes idênticos, mas também podem ser e frequentemente são diferentes. Tive casos em que a discrepância é enorme, mais de 50% em alguns casos, mas normalmente é algo como <1% vs 15-30%. O resultado das consultas é quase sempre o percentual mais alto.

A reconstrução do índice zerará completamente ou quase esses dois números (embora não necessariamente ambos sejam zero). Portanto, agora tenho 2 números para fragmentação em um índice. De acordo com a documentação de sys.dm_db_index_physical_stats e Index Properties (FragmentationPage) , ambos devem ser a fragmentação lógica do índice, portanto, devem sempre ser o mesmo número. Como é que estou obtendo números diferentes para o que deveria ser a mesma estatística?

Constantemente vejo as pessoas dizerem que os índices ficam mais lentos updatee delete. insertIsso é usado como uma declaração geral, como se fosse um absoluto.

Ao ajustar meu banco de dados para melhorar o desempenho, continuo me deparando com essa situação que parece contradizer essa regra logicamente para mim, e em nenhum lugar posso encontrar alguém que diga ou explique de outra forma.

No SQL Server, e acredito/presumo que a maioria dos outros DBMS, seus índices são criados com base em colunas específicas que você especifica. Inserções e exclusões sempre afetarão uma linha inteira, portanto, não há como não afetar o índice, mas as atualizações parecem um pouco mais exclusivas, elas podem afetar especificamente apenas determinadas colunas.

Se eu tenho colunas que não estão incluídas em nenhum índice e as atualizo, elas ficam lentas apenas porque tenho um índice em outras colunas dessa tabela?

Como exemplo, digamos que na minha Usertabela eu tenha um ou dois índices, a chave primária que é uma coluna de Incremento de Identidade/Auto e possivelmente outra em alguma coluna de chave estrangeira.
Se eu atualizar uma coluna sem o índice diretamente nela, como, digamos, seu número de telefone ou endereço, essa atualização fica mais lenta porque tenho índices nesta tabela em outras colunas em qualquer situação? As colunas que estou atualizando não estão em índices, então, logicamente, os índices não deveriam ser atualizados, não deveriam? Se alguma coisa, eu acho que eles são acelerados se eu usar os índices na cláusula WHERE.