Se eu eliminar minha PK em cluster e adicionar uma nova, em que ordem minhas linhas estarão?

Question

No SQL Server, estou observando a TableA, que atualmente possui uma chave primária em cluster uniqueidentifier. O GUID não tem significado em nenhum contexto.

(Vou te dar um segundo para limpar o teclado e o monitor e largar o refrigerante.)

Gostaria de eliminar essa chave primária e adicionar uma nova chave primária de número inteiro exclusivo à tabela. Minha pergunta é: quando eu derrubar o índice, modificar a coluna de uniqueidentifier para int e adicionar a nova chave primária exclusiva em cluster à coluna modificada, os novos valores PK estarão na ordem de inserção na tabela, ou eles serão estar em alguma outra ordem? Este é o caminho certo para ir aqui? Isso vai funcionar? (Eu sou meio que um noobkin no que diz respeito à criação / modificação de tabelas).

    

Answer 1

Quando você solta um índice clusterizado, a tabela se torna um heap. Como os heaps têm uma estrutura física muito diferente dos índices, os dados terão que ser copiados para a nova estrutura. Heaps não tem ordem alguma. Quando você adiciona de volta 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ê deseja preservar a ordem existente, tudo o que 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 de Integer_Ids corresponderá à ordem de Guids. Você pode descartar a coluna Guid e adicionar um índice clusterizado na nova coluna Integer e a ordem física dos registros foi preservada.

    

Answer 2

Por definição, um índice clusterizado impõe uma ordenação física em páginas de dados reais; então, sim, se você soltar um índice clusterizado e criar um novo, isso forçará um reordenamento físico dos dados.

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

• O índice clusterizado existente será descartado, mas os dados reais no disco não serão movidos por causa disso.
• Você modificará o tipo de coluna (ou soltará 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 não até mesmo deixá-lo adicionar como não saberia o que colocar nele).
• Neste ponto, a coluna será preenchida automaticamente pelo SQL Server. Não sei ao certo o que acontecerá aqui, mas acho que será preenchido na ordem em que as linhas são armazenadas fisicamente no banco de dados. Mas eu estou apenas supondo sobre isso.
• O problema é que o pedido pode ser bastante confuso quando os UIDs estão envolvidos; então você não sabe como os dados são realmente armazenados agora, e você não sabe como eles serão armazenados posteriormente; Se meu palpite sobre a população da coluna estiver correto, não haverá uma enorme reordenação ... mas pode acontecer; e, mesmo se eu estiver correto, o edifício do índice vai demorar um pouco, se a tabela for grande o suficiente.

Resumindo: você terá um impacto enorme, e você poderá obter linhas de um SELECT não ordenado na mesma ordem que você os recebe agora. Você terá que tentar.

    

Answer 3

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

    

Answer 4

Se você criar uma tabela com uma chave primária em cluster e, em seguida, eliminar a PK em cluster, a ordem física dos dados na tabela não será perturbada. No entanto, não é garantido que a ordem física dos resultados da consulta seja a mesma da ordem na tabela, portanto, essa ordenação é bastante insignificante.

Se você adicionar uma coluna de número inteiro e criar uma chave primária em cluster, a tabela será reorganizada na ordem em que a chave é classificada. Isso pode ou não ser a mesma ordem física do GUID, dependendo de como a chave está atribuído. Você poderia atribuí-lo explicitamente com base na ordem de classificação da chave GUID (por exemplo, usando row_number () sobre a ordem antiga de chaves) ou atribuir-lhe outra maneira. A menos que você tome medidas para garantir que a ordenação seja explicitamente feita da mesma forma, a ordem física ou as linhas na tabela não terão a garantia de orientar a ordenação da nova chave.