0
큰 SQL Server 2008 데이터 테이블의 기본 키의 경우 guids 또는 거의 동일한 크기의 문자열을 사용할 수 있습니다.guids의 성능을 SQL의 문자열과 비교하는 방법
성능 측면에서 볼 때 guid (16 바이트)는 약 16 자의 문자열과 비교할 때 조인, 선택 등을 수행 할 때 어떻게됩니까? 내부적으로 숫자로 표시되기 때문에 SQL을 처리하는 것이 더 좋습니까?
A
답변
2
귀하의 질문에 대한 짧은 대답은 이상적으로 어느 것도 사용하지 않는 것입니다.
int/bigint 키 (related question에 대한 답변에서 제안한대로)를 사용할 수 있으면 좋습니다.
둘 이상의 SQL Server 인스턴스에 저장된이 데이터 집합의 복사본을 비파괴 적으로 병합하는 기능이 필요하지 않으면 GUID 기본 키를 사용하면 인덱스 유지 관리에 상당한 오버 헤드가 추가됩니다. This article에 문제에 대한 합리적인 논의가 있습니다.
생성하는 시퀀스가 일관되게 정렬되면 문자열 PK의 오버 헤드가 적어야합니다. 즉, 새 값은 항상 테이블의 '끝에'추가됩니다.
+0
미래에 데이터 병합이 요구 될 수 있습니다. 아마 그 당시에는 기사 링크에서 설명한대로 추가 "서버 ID"로 해결할 수 있습니다. – Carvellis
데이터를 연결하기 위해 int 또는 숫자 데이터 유형을 선택하는 이유는 무엇일까? –
성능에 대해서는 확실하지 않지만 Wadih의 경우 : =>이 테이블에 대한 모든 FK는 이제 16 바이트 너비의 오버 헤드를 전달합니다. => char/guid가 무작위로 배포되는 경우 다른 페이지 분할이 발생할 수 있으므로 클러스터 된 인덱스를 16 바이트 PK에서 변경하는 것이 좋습니다. => 고정 폭 문자를 사용하는 것이 좋습니다 (예 : varchar (16) – StuartLC
나중에 데이터를 병합하는 것이 필요할 수 있으므로 guid를 사용합니다. 나는 아마도 어쨌든 bigint에 갈 것이지만, 전문적인 관심에서, 나는 여전히 그들이 어떻게 비교하는지 알고 싶다. – Carvellis