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.
so there is no way they will not affect the indexexceto para índices filtrados ...
Penso no índice não coberto e não agrupado como contendo ponteiros para registros (normalmente nos nós das folhas de índice agrupadas da tabela). Eu pensaria que uma situação causaria uma desaceleração durante um UPDATE (de um atributo não incluído) pode ser uma situação em que o UPDATE fez com que o registro se movesse dentro do índice clusterizado. Ainda não tenho certeza se um movimento faria o ponteiro mudar, OU se o ponteiro é simplesmente um valor KEY no índice clusterizado; nesse caso, a possível atualização do local não importaria, porque o sistema faria apenas uma pesquisa KEY para obter o valor do registro.
— Jmoney38
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.
SQL Server é mencionado no OP, eu adicionei uma tag, então eu acho que você pode assumir SQL Server
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:
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.
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.
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.
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.
"O caminho do código necessário para uma atualização quando o índice não será afetado ainda precisa ser avaliado" isso não é verdade. A fase de compilação / otimização saberá muito bem quais índices precisam ser atualizados, se houver, e criará o plano adequadamente. Uma instrução UPDATE que não modifica (declara na lista SET) colunas de um índice (incluindo INCLUDE e colunas de chaves em cluster) não precisará atualizar esse índice e a fase de execução nem sequer o tocará. DELETE e INSERT obviamente tocam em todas as colunas (logicamente) e precisam atualizar todos os índices.
@RemusRusanu, mas ele não precisará ser avaliado se o índice puder ser usado para localizar as linhas que precisam ser atualizadas?
@RemusRusanu - Suponho que uma vez que o QO tenha compilado um plano, não será necessário mais CPU; no entanto, para compilar o plano, ele certamente precisa fazer isso. Se os planos estão sendo compilados com frequência, isso pode fazer uma pequena diferença.
@TomV usando o índice para localizar as linhas candidatas a excluir / atualizar é um tópico totalmente diferente. Se for esse o caso, as vantagens de localizar as linhas por meio de um índice devem superar os problemas de custo de manutenção do índice.
@ MaxVernon eu diria que não há cenário válido de recompilações freqüentes de DML (UPDATE). Eu compro alguns casos para recompilações válidas (inevitáveis?) Para consultas ad-hoc. Mas DML? Que tipo de aplicativo pode criar instruções UPDATE únicas e ad-hoc? As recompilações frequentes com o DML gritam "Parameterize me".
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.