9
많은 수의 행 (10K +)이있는 테이블을 가지며 기본 키는 GUID입니다. 기본 키가 클러스터됩니다. 이 테이블에서는 쿼리 성능이 매우 낮습니다. 효율적으로하기위한 제안을하십시오.클러스터 인덱스 GUID 기본 키의 성능 향상
A
답변
4
+3
newsequentialid()에 대해 많이 읽었지만 SQL 함수 인 것 같습니다. Guid가 Code (C#)에서 생성되는 경우 수행 할 작업을 누군가에게 알려줄 수 있습니까? –
+0
-1이 답변은 인덱스의 물리적 클러스터링과 관련이 있습니까? 그 질문을하는 사람은 이미 그/그녀가 10K + 행을 가지고 있고 그/그녀는 아마도 모든 키를 바꾸고 싶어하지 않는다고 말했습니다. – nashwan
2
순차 GUIDS를 사용해보십시오. 그러면 순차적 GUIDS를 사용하여 인덱스를보다 효과적으로 만들 수 있습니다. 정보 here.
38
GUID의 클러스터 된 인덱스는 좋은 디자인이 아닙니다. GUID의 특성상 무작위입니다. 클러스터 된 인덱스는 물리적으로 키에 의해 레코드를 정렬합니다. 두 가지가 완전히 다릅니다. 모든 삽입 SQL에 대해 디스크의 레코드를 재정렬해야합니다! 이 색인에서 클러스터링을 제거하십시오!
클러스터링을 사용하는 시간은 데이터에 대한 "자연스러운"순서 (삽입 시간, 계좌 번호 등)가있는 경우입니다. 시간 필드의 경우 클러스터링은 거의 무료입니다. 계좌 번호는 무료 또는 저렴한 금액 (계좌 번호가 순차적으로 할당 된 경우) 일 수 있습니다.
GUID 문제와 관련하여 기술적 인 방법이있을 수 있지만 클러스터링을 사용해야하는 경우를 이해하는 것이 가장 좋습니다.
+3
가혹한 음색의 경우 +1. 이 질문에는 회색 부분이별로 없습니다. 하지 마. – Droogans
-5
이 lenghty 문자열 열에 대한 클러스터 된 인덱스를 만들지 않도록하십시오 여기 참조) (NEWSEQUENTIALID 사용해야합니다. GUID는 36 자입니다. 클러스터 된 인덱스로 작성한 경우에도 쿼리 성능이 저하됩니다. 더 나은 실행을 위해 정수 ID 열을 사용하십시오.
1
쿼리를 분석해야합니다. SQL Server 나 Oracle에서 쉽게 얻을 수있는 실행 계획을 보지 않고도 쿼리가 왜 성능이 좋지 않은지 추측 할 수 있습니다.
GUID가 128 비트 값 (원시로 저장되는 경우) 인 것으로 간주하면 GUID는 데이터 및 인덱스 블록의 밀도를 기본 키 인덱스의 경우 50 %만큼 줄입니다. GUID가 적절합니다.
하지만 문제가되지 않을 수 있으므로 쿼리 계획을 검토하십시오. 다른 여러 문제가 될 수 있습니다.
7
GUID를 기본 키로 사용하는 데는 문제가 없습니다. 실제로 GUID를 기본 키로 설정하면 자동으로 생성되는 인덱스를 Non-clustered 유형으로 설정하십시오. 많은 사람들이 SQL Server에서이 작업을 수행하는 것을 잊어 버립니다 (또는 모릅니다).
GUID에는 클러스터 된 인덱스를 사용하지 마십시오. 이로 인해 디스크상의 GUID 주위에 물리적 인 순서가 발생합니다 (다른 것들은 이미 지적했듯이).
GUID를 기본 키로 사용하고 특히 성능과 관련하여 가장 좋은 방법은 무엇입니까? (http://stackoverflow.com/questions/11938044/what-are-the-best-practices-for-using-a-guid-as-a-primary-key-specifically-rega) – AHiggins
클러스터되지 않도록하십시오! (GUID로 유지해야하는 경우) – nashwan