SQL Server에서는 현재 고유 식별자 클러스터형 기본 키가 있는 TableA를 보고 있습니다. GUID는 어떤 상황에서도 의미가 없습니다.
(키보드와 모니터를 청소하고 탄산음료를 내려 놓을 수 있도록 잠시 시간을 드리겠습니다.)
해당 기본 키를 삭제하고 새로운 고유 정수 기본 키를 테이블에 추가하고 싶습니다. 내 질문은 다음과 같습니다. 인덱스를 삭제하고 열을 Uniqueidentifier에서 int로 수정하고 새 클러스터 고유 기본 키를 수정된 열에 추가하면 새 PK 값이 테이블에 삽입된 순서대로 표시됩니까, 아니면 다른 순서인가요? 여기로 가는 길이 맞나요? 이것이 작동할까요? (나는 테이블 생성/수정에 관해서는 일종의 멍청한 사람입니다.)
답변1
클러스터형 인덱스를 삭제하면 테이블이 힙이 됩니다. 힙은 인덱스와 물리적 구조가 매우 다르기 때문에 데이터를 새 구조에 복사해야 합니다. 힙에는 순서가 없습니다. 새 클러스터형 인덱스를 다시 추가하면 데이터가 힙에서 새 인덱스로 복사되고 순서는 새 클러스터형 키에 의해 정의됩니다.
기존 순서를 유지하려면 새 정수 ID를 올바르게 할당하기만 하면 됩니다.
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;
이제 Integer_Ids의 순서가 Guids의 순서와 일치합니다. Guid 열을 삭제하고 새 Integer 열에 클러스터형 인덱스를 추가하면 레코드의 물리적 순서가 유지됩니다.
답변2
정의에 따르면 클러스터형 인덱스는 실제 데이터 페이지에 물리적 순서를 적용합니다. 그렇습니다. 클러스터형 인덱스를 삭제하고 새 인덱스를 생성하면 데이터가 물리적으로 다시 정렬됩니다.
귀하의 경우 다음과 같은 일이 일어날 것이라고 가정하는 것이 안전하다고 생각합니다.
- 기존 클러스터형 인덱스는 삭제되지만 이로 인해 디스크의 실제 데이터는 이동되지 않습니다.
- 열 유형을 수정하거나(또는 기존 열을 삭제하고 새 열을 생성) null, 고유, 기본 키, ID 및 자동 증가가 아니도록 제약 조건을 설정합니다(이는 매우 중요합니다. 그렇지 않으면 SQL Server에서는 허용하지 않습니다). 무엇을 넣어야 할지 모르므로 추가하세요.)
- 이 시점에서 열은 SQL Server에 의해 자동으로 채워집니다. 여기서 무슨 일이 일어날지는 확실하지 않지만,생각하다행이 데이터베이스에 물리적으로 저장된 순서대로 채워집니다. 하지만 나는 이것에 대해 추측하고 있습니다.
- 문제는 UID가 관련되면 주문이 매우 지저분해질 수 있다는 것입니다. 따라서 현재 데이터가 실제로 어떻게 저장되는지 모르고 나중에 어떻게 저장될지 알 수 없습니다. 열 채우기에 대한 내 추측이 정확하다면 큰 재정렬은 없을 것입니다... 하지만 그런 일이 일어날 수 있습니다. 그리고 제가 옳다고 하더라도 테이블이 충분히 크면 인덱스 구축에 시간이 좀 걸릴 것입니다.
결론: 당신~ 할 것이다큰 영향을 미치고 당신은~할 수 있었다지금 얻는 순서와 동일한 순서로 순서가 지정되지 않은 SELECT에서 행을 가져옵니다. 당신은 시도해야 할 것입니다.
답변3
클러스터형 인덱스는 정의에 따라 데이터의 물리적 순서를 결정하므로 새 클러스터형 인덱스를 만들면 데이터 순서가 변경됩니다. 테이블이 크다면 시간이 좀 걸릴 것으로 예상하세요.
답변4
클러스터된 기본 키를 사용하여 테이블을 생성한 다음 클러스터된 PK를 삭제하면 테이블에 있는 데이터의 물리적 순서가 그대로 유지됩니다. 그러나 쿼리 결과의 물리적 순서는 테이블의 순서와 동일하다고 보장할 수 없으므로 이러한 순서는 큰 의미가 없습니다.
그런 다음 정수 열을 추가하고 여기에 클러스터된 기본 키를 생성하면 키가 정렬되는 순서에 따라 테이블이 다시 정렬됩니다. 이는 키 할당 방법에 따라 GUID와 동일한 물리적 순서일 수도 있고 아닐 수도 있습니다. GUID 키의 정렬 순서에 따라 명시적으로 할당하거나(예: 이전 키 순서 대신 row_number() 사용) 다른 방식으로 할당할 수 있습니다. 순서가 명시적으로 물리적 순서와 동일하도록 보장하는 조치를 취하지 않거나 테이블의 행이 새 키의 순서를 구동한다고 보장할 수는 없습니다.