Se eu descartar meu PK clusterizado e adicionar um novo, em que ordem minhas linhas estarão?

Question

No SQL Server, estou analisando a TabelaA, que atualmente possui uma chave primária clusterizada com identificador exclusivo. O GUID não tem significado em nenhum contexto.

(Vou lhe dar um segundo para limpar o teclado e o monitor e colocar o refrigerante na mesa.)

Gostaria de eliminar essa chave primária e adicionar uma nova chave primária inteira exclusiva à tabela. Minha pergunta é a seguinte: quando eu eliminar o índice, modificar a coluna de uniqueidentifier para int e adicionar a nova chave primária exclusiva agrupada à coluna modificada, os novos valores de PK estarão na ordem de inserção na tabela ou serão estar em alguma outra ordem? Este é o caminho certo a seguir aqui? Isso vai funcionar? (Eu sou meio novato em relação à criação/modificação de tabelas.)

Answer 1

Quando você elimina um índice clusterizado, a tabela se torna um heap. Como os heaps possuem uma estrutura física muito diferente dos índices, os dados terão que ser copiados para a nova estrutura. Montes não têm ordem alguma. Ao adicionar novamente um novo índice clusterizado, os dados serão copiados do heap para o novo índice e a ordem será definida pela nova chave clusterizada.

Se você quiser preservar a ordem existente, tudo o que você precisa fazer é atribuir os novos IDs inteiros corretamente:

ALTER TABLE Table ADD Integer_Id INT;
GO

WITH cte AS (
  SELECT ROW_NUMBER() OVER (ORDER BY Guid_Id) as RowOrderByGuid,
    Guid_Id
  FROM Table)
UPDATE t
  SET t.Integer_Id = c.RowOrderByGuid
FROM Table t
JOIN cte c ON t.Guid_Id = c.Guid_Id;

Agora a ordem dos Integer_Ids corresponderá à ordem dos Guids. Você pode eliminar a coluna Guid e adicionar um índice clusterizado na nova coluna Integer e a ordem física dos registros será preservada.

Answer 2

Por definição, um índice clusterizado impõe uma ordem física nas páginas de dados reais; então, sim, se você eliminar um índice clusterizado e criar um novo, isso forçará uma reordenação física dos dados.

No seu caso, acho seguro presumir que o seguinte acontecerá:

• O índice clusterizado existente será eliminado, mas os dados reais no disco não serão movidos por causa disso.
• Você modificará o tipo de coluna (ou eliminará a coluna existente e criará uma nova), definindo restrições para que ela não seja nula, exclusiva, chave primária, identidade e incremento automático (isso é vital, ou o SQL Server nem permitirá que você adicione-o, pois não saberia o que colocar nele).
• Neste ponto, a coluna será preenchida automaticamente pelo SQL Server. Não sei ao certo o que vai acontecer aqui, maspensarele será preenchido na ordem em que as linhas são armazenadas fisicamente no banco de dados. Mas estou apenas supondo isso.
• O problema é que o pedido pode ser bastante confuso quando há UIDs envolvidos; então você não sabe como os dados são realmente armazenados agora e não sabe como serão armazenados mais tarde; se minha suposição sobre a população da coluna estiver correta, não haverá uma grande reordenação... mas pode acontecer; e, mesmo que eu esteja correto, a construção do índice vai demorar um pouco, se a tabela for grande o suficiente.

Resumindo: vocêvaitem um impacto enorme, e vocêpoderiaobtenha linhas de um SELECT não ordenado na mesma ordem em que você as obtém agora. Você terá que tentar.

Answer 3

Um índice clusterizado, por definição, determina a ordem física dos dados, portanto, quando você criar o novo índice clusterizado, os dados serão reordenados; se for uma mesa grande, planeje que demore um pouco.

Answer 4

Se você criar uma tabela com uma chave primária clusterizada e, em seguida, descartar a PK clusterizada, a ordem física dos dados na tabela não será perturbada. No entanto, não há garantia de que a ordem física dos resultados da consulta seja igual à ordem na tabela, portanto, essa ordem não tem sentido.

Se você adicionar uma coluna inteira e criar uma chave primária agrupada nela, a tabela será reorganizada em qualquer ordem em que a chave for classificada. Esta pode ou não ser a mesma ordem física do GUID, dependendo de como a chave é atribuída. Você pode atribuí-lo explicitamente com base na ordem de classificação da chave GUID (por exemplo, usando row_number() sobre a ordem antiga da chave) ou pode atribuí-lo de alguma outra maneira. A menos que você tome medidas para garantir que a ordem seja explicitamente igual, não há garantia de que a ordem física ou as linhas da tabela conduzam a ordem de sua nova chave.