Efeito de um índice nas instruções de atualização em que a coluna de atualização não está em um índice

Eu sempre ver as pessoas dizem que os índices abrandar update, deletee insert. Isso é usado como uma declaração geral, como se fosse um absoluto.

Enquanto ajusto meu banco de dados para melhorar o desempenho, continuo encontrando essa situação que parece contradizer essa regra logicamente para mim, e em nenhum lugar encontro alguém que diga ou explique de outra forma.

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

Se eu tiver colunas que não estão incluídas em nenhum índice e atualizá-las, elas ficarão mais lentas apenas porque eu tenho um índice em outras colunas nessa tabela?

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

Você está certo de que atualizar uma coluna não indexada não causará alterações nos índices. Em um caso simples, também não haveria impacto geral sobre a mesa.

Se uma consulta puder usar o Índice para pesquisar dados, isso poderá acelerar a pesquisa, mas o comportamento exato (dependendo da sua marca SQL) poderá diferir de outras marcas do SQL. (Eu uso principalmente o Microsoft SQL Server.)

Obviamente, atualizar uma coluna com um volume significativamente maior de dados pode causar alguma movimentação de linhas para páginas diferentes, etc.

Para um sistema moderno relativamente rápido, a adição de um único índice a uma tabela OLTP provavelmente será praticamente indetectável do ponto de vista de desempenho para a grande maioria dos sistemas . Dito isto, você não deve criar índices desnecessários e provavelmente não deve criar índices de coluna única para todas as colunas da tabela.

Você está correto no pressuposto de que, para muitas consultas, a presença de índices úteis resultará em uma melhoria de velocidade muito perceptível.

Embora sua pergunta pareça estar relacionada ao desempenho, existem vários outros problemas em potencial na adição de índices, incluindo, entre outros:

1. O tempo necessário para criar o índice pode resultar em bloqueio enquanto o índice é adicionado à tabela. O bloqueio é de vida muito curta e provavelmente não criará um grande problema.

2. As alterações no índice resultam na invalidação dos planos de execução para quaisquer planos que façam referência à tabela subjacente. Quando esses planos de execução são recompilados, o desempenho pode mudar negativamente para algumas consultas.

3. Modificações no índice podem resultar em consultas retornando erros onde nenhuma foi retornada anteriormente. Veja o caso de um índice filtrado que foi usado para retornar datas contidas em um campo varchar; se o filtro eliminou as linhas que não eram datas e esse filtro foi alterado posteriormente, as consultas que se baseavam nesse índice agora podem falhar ao tentar converter dados que não são de data.

4. Um novo índice pode fazer com que a ordem de execução seja alterada, resultando em possíveis deadlocks onde não havia ocorrido antes.

Se a operação de atualização tiver como alvo uma coluna não indexada de tamanho fixo (como um número inteiro), geralmente não deve ser lenta, mas comparada a uma instrução select, a atualização também deve eventualmente ser gravada no disco lento.