[sql-server] 성능과 관련하여 GUID를 기본 키로 사용하는 가장 좋은 방법은 무엇입니까?

GUID는 기본 키의 자연스러운 선택으로 보일 수 있습니다. 실제로 필요한 경우 테이블의 PRIMARY KEY에 사용할 수도 있습니다. 내가 하지 말 것을 강력히 권유 하는 것은 GUID 열을 클러스터링 키로 사용하는 것입니다. 특별히 명시하지 않는 한 SQL Server는 기본적으로 SQL Server에서 수행합니다.

실제로 두 가지 문제를 구분해야합니다.

1. 기본 키는 논리적 구조입니다 – 고유 안정적으로 테이블의 모든 행을 식별하는 후보 키 중 하나. 이 할 수있는 일, 정말 – INT하는 GUID문자열 – 당신의 시나리오에 가장 적합한 것을 선택합니다.

2. 클러스터링 키 (열 또는 테이블의 “클러스터 된 인덱스”를 정의 열) -이 인 물리적 작은, 안정, 계속 증가하는 데이터 타입이 최선의 선택이다, 여기에 스토리지 관련 것, 그리고 – INT또는 BIGINT로 기본 옵션.

기본적으로 SQL Server 테이블의 기본 키는 클러스터링 키로도 사용되지만 반드시 그럴 필요는 없습니다! 이전 GUID 기반 기본 / 클러스터 키를 GUID의 기본 (논리) 키와 별도의 INT IDENTITY(1,1)열의 클러스터링 (순서화) 키로 분리 할 때 개인적으로 엄청난 성능 향상을 보았습니다 .

로 킴벌리 트립 인덱싱의 여왕 – – 그리고 다른 좋은 여러 번 언급 한 – GUID클러스터링 키가 무작위로 인한 때문에, 대규모 페이지와 인덱스 조각에 일반적으로 나쁜 성능으로 이어질 것입니다, 최적 아니므로.

예, 알고 있습니다 newsequentialid(). SQL Server 2005 이상이 있습니다. 그러나 그것은 심지어 완전하고 순차적이지 않으므로 동일한 문제로 인해 GUID덜 두드러지게 나타납니다.

고려해야 할 또 다른 문제가 있습니다. 테이블의 클러스터링 키가 테이블의 각 클러스터되지 않은 인덱스의 각 항목에 추가되므로 가능한 한 작게 만들어야합니다. 일반적으로 INT2 십억 행 이상의 행이 대부분의 테이블에 충분해야합니다 GUID. 클러스터링 키 와 비교하면 디스크와 서버 메모리에 수백 메가 바이트의 스토리지를 절약 할 수 있습니다.

빠른 계산 INT-vs. GUID를 기본 및 클러스터링 키로 사용 :

• 1’000’000 개의 행이있는 기본 테이블 (3.8MB vs. 15.26MB)
• 비 클러스터형 인덱스 6 개 (22.89MB vs. 91.55MB)

총계 : 25MB 대 106MB- 단일 테이블에 있습니다.

킴벌리 트립 (Kimberly Tripp)의 훌륭한 재료-생각을위한 음식이 더 있습니다. 읽고, 다시 읽고, 소화하십시오! 실제로 SQL Server 인덱싱 복음입니다.

• 기본 키 및 / 또는 클러스터 키와 같은 GUID
• 클러스터형 인덱스 토론 계속
• 계속 증가하는 클러스터링 키-클러스터형 인덱스 토론 ………. 다시!
• 디스크 공간이 저렴 합니다. 요점 이 아닙니다 !

추신 : 물론, 수백 또는 수천 행을 다루는 경우 이러한 인수의 대부분은 실제로 당신에게 큰 영향을 미치지 않습니다. 그러나 : 당신이 수십 또는 수백 행의 수천에 들어가, 또는 수백만에서 계산을 시작하는 경우 – 다음 그 점은 매우 중요하고 이해하기 매우 중요하게된다.

업데이트 : 당신은 당신이 원하는 경우 PKGUID기본 키로 열 (그러나 클러스터링 키) 및 다른 열 MYINT( INT IDENTITY클러스터링 키 등이) – 이것을 사용 :

CREATE TABLE dbo.MyTable
(PKGUID UNIQUEIDENTIFIER NOT NULL,
 MyINT INT IDENTITY(1,1) NOT NULL,
 .... add more columns as needed ...... )

ALTER TABLE dbo.MyTable
ADD CONSTRAINT PK_MyTable
PRIMARY KEY NONCLUSTERED (PKGUID)

CREATE UNIQUE CLUSTERED INDEX CIX_MyTable ON dbo.MyTable(MyINT)

기본적으로 제약 조건 을 명시 적으로 명시 해야합니다 (그렇지 않으면 기본적으로 클러스터형 인덱스로 생성됩니다). 그런 다음 정의 된 두 번째 인덱스를 만듭니다.PRIMARY KEYNONCLUSTEREDCLUSTERED

이것은 작동하며 성능을 위해 “재 설계”되어야하는 기존 시스템이있는 경우 유효한 옵션입니다. 새로운 시스템의 경우 처음부터 시작하고 복제 시나리오가 아닌 경우 항상 ID INT IDENTITY(1,1)다른 어떤 것보다 훨씬 효율적인 클러스터 된 기본 키로 선택 합니다!

답변

CREATE TABLE [Core].[Email] (
    [EmailID]      UNIQUEIDENTIFIER CONSTRAINT [DF_Email_EmailID] DEFAULT (newsequentialid()) NOT NULL,
    [EmailAddress] NVARCHAR (50)    CONSTRAINT [DF_Email_EmailAddress] DEFAULT ('') NOT NULL,
    [CreatedDate]  DATETIME         CONSTRAINT [DF_Email_CreatedDate] DEFAULT (getutcdate()) NOT NULL,
    [ClusterID] INT NOT NULL IDENTITY,
    CONSTRAINT [PK_Email] PRIMARY KEY NonCLUSTERED ([EmailID] ASC)
);
GO

CREATE UNIQUE CLUSTERED INDEX [IX_Email_ClusterID] ON [Core].[Email] ([ClusterID])
GO

CREATE UNIQUE NONCLUSTERED INDEX [IX_Email_EmailAddress] ON [Core].[Email] ([EmailAddress] Asc)