Usando: SQL Server 2008 R2
No momento, estou percorrendo um plano de execução de consulta e encontrei uma instância de atualização de índice clusterizado em uma tabela. O problema aqui é que as colunas que estão sendo atualizadas NÃO fazem parte do índice clusterizado.
Mesa:
<table>
id INT IDENTITY(1,1) -- Clustered Index
, name VARCHAR(20) -- Nonclustered Index
, status CHAR(1)
, quantity INT
, price FLOAT
Declaração de atualização:
UPDATE a
SET a.status = @status
, a.quantity = @quantity
, a.price = @price
FROM <table> a
WHERE a.name = @name
O plano de execução mostra um Eager Spool com custo de 36%, uma atualização de índice clusterizado com custo de 55% e uma busca de índice no índice de nome com 9%, entre os itens Compute Scalar e Top com custo de 0%.
Por que o plano está mostrando uma atualização de índice clusterizado? O que eu poderia fazer para evitar isso e evitar o carretel ansioso?
Quando você tem um índice clusterizado em uma tabela, o índice clusterizado É a tabela!
Mentalmente, você pode substituir "tabela" por "índice agrupado" neste caso e fará sentido.
Os dados de cada campo em cada linha estão em seu índice clusterizado. O índice clusterizado apenas define a ordem das páginas físicas no banco de dados a serem organizadas por sua(s) chave(s) de clustering.
Você sempre pode recorrer à analogia da lista telefônica para essas coisas também: em sua lista telefônica clássica, os dados são agrupados em
Last Name, First Name. Cada entrada ainda temPhoneNum, Addressno nível da folha, mas você não ordena por isso. As páginas estão em ordem física pelas teclas.Não posso aconselhar sobre como otimizar a consulta, a menos que você nos mostre a tabela e a consulta que está executando, mas basicamente esse custo será pago de uma forma ou de outra. Se você não atualizar o índice clusterizado, será uma atualização de tabela e uma varredura de tabela.