데이터베이스 설계에서는 종종 guid나 int를 주 키로 사용하는데, 우리가 배운 지식에 따르면 int가 주 키로 더 효율적이라고 항상 느꼈지만, 신중한 테스트 없이는 불가능합니다
이유를 설명해 주세요. 오늘 데이터베이스 최적화 중에 이 문제를 만나서 테스트를 해봤습니다.
시험 환경:
데스크탑 PC 펜티운(R) 4 CPU 3.06GHz 윈 XP 프로페셔널 1.5G DDR RAM SQL Server 2005 개인용
테스트 과정:
먼저, 테스트 데이터베이스를 만들어, 테스트
검사 결과는 다음과 같습니다:
앞서 언급했듯이, int를 주 키로 사용하는 것이 guid를 주 키로 사용하는 것보다 효율성이 향상되며, 특히 연결 쿼리와 레코드 삭제가 있을 때 더욱 그렇습니다.
게다가 오늘날 GUID의 메인 키를 가진 데이터 쿼리에서는 여러 하위 쿼리 결과가 중첩되어 쿼리 타임아웃이 반복적으로 발생했습니다. 그래서 저는 int를 주 키로 사용하는 것에 찬성하며, guid를 주 키로 사용하는 것에는 동의하지 않습니다. 위의 견해는 개인적인 의견이며, 누구나 의견을 표현하고 가이드와 지능을 주요 키로 사용하는 장단점을 설명할 수 있습니다.
추적 검사:
형제들의 상기시켜준 후, 오늘 두 개의 하위 테이블에 클러스터가 없는 인덱스가 추가되었습니다:
Test_Guid_Detail(가이드)에서 비클러스터 인덱스 Index_Detail_Guid 생성하기 Test_Int_Detail(ID)에서 비클러스터 인덱스 Index_Detail_id 생성하기 그 후 내부 연결 조사를 진행했는데, 샤오샤 @Xu 말씀처럼 효율이 50%를 넘기에는 명확하지 않고, 기본적으로 약 23% 정도의 향상에 불과해 여전히 허용 가능한 수준임을 알게 되었습니다.
따라서 권장합니다
1. 데이터 마이그레이션이 자주 필요한 시스템에서는 Guid를 사용하는 것이 권장됩니다. 그리고 해당 외래키 필드, 즉 조인 쿼리에 사용되는 필드에 비클러스터 인덱스를 추가하면 성능 향상에 큰 도움이 됩니다. 여기서 조건의 필드는 비클러스터 인덱스에 대해서도 적절히 추가할 수 있습니다.
2. Guid 타입을 기본 키로 사용할 때는 데이터 타입을 고유식별자(uniqueidentifier)로 설정해야 하며, 기본 키의 "집계 인덱스"는 반드시 취소하는 것을 잊지 마세요
3. 마이그레이션이 필요 없는 시스템이나 소규모 시스템의 경우, int를 기본 키로 사용하는 것이 여전히 매우 편리하며, 효율성도 어느 정도 향상됩니다.
|