저는 회사가 시작하는 새 데이터베이스에 대한 데이터베이스 표준 작업을하고 있습니다. 우리가 정의하려고하는 것 중 하나는 UniqueIdentifier와 관련하여 Primary Key와 Clustered Index 규칙입니다.NewSequentialId UniqueIdentifier 클러스터 된 인덱스
(참고 : UniqueIdentifier를 기본 키 또는 클러스터 된 인덱스로 사용하는 장단점에 대한 토론은 필요하지 않습니다.이 웹에 대한 정보는 많습니다. 아니요, 토론입니다.
내가 클러스터 된 인덱스 및 기본 키와 같은 고유 식별자로 테이블을 말해봐 :)
그래서 날 여기 걱정이있는 시나리오입니다. ColA라고 부르 자. ColA의 기본값을 NewSequentialId()로 설정했습니다. 사용
그 NEWSEQUENTIALID() 나는 세 개의 연속 된 행 삽입 :
{72586AA4-D2C3-440D-A9FE-CC7988DDF065}
{72586AA4-D2C3-440D-A9FE-CC7988DDF066}
{72586AA4-D2C3-을 440D-A9FE-CC7988DDF067}
그런 다음 서버를 재부팅합니다. docs for NewSequentialId은 "Windows를 다시 시작한 후 GUID는 낮은 범위에서 다시 시작할 수 있지만 여전히 전역 적으로 고유합니다."라고 말합니다.
그래서 다음 출발점은 이전 범위보다 낮을 수 있습니다.
{35729A0C-F016-4645-ABA9-B098D2003E64}
{35729A0C-F016-4645-ABA9-B098D2003E65}
{35729A0C-F016- :
그래서 다시 시작 후에, 나는 3 개 이상의 값을 삽입 4645-ABA9-B098D2003E66}
(정확히 guid가 데이터베이스에 표시되는 방법을 잘 모르겠지만이 중 하나가 3으로 시작하고 이전 값이 7로 시작 되었기 때문에 3이 "작다" 7 개)
삽입물을 삽입하면 클러스터 된 인덱스 중간에서 인덱스 재 매핑이 발생해야합니다. (최소한 내 DBA는 나에게 말했습니다.) 그리고 재부팅 할 때마다 새로운 UniqueIdentifier 범위가 다른 이전 범위의 중간에 올 위험이 있습니다.
그럼 내 질문입니다 : 다음 세트의 고유 식별자가 마지막 세트보다 작을 것이기 때문에 모든 삽입으로 인해 클러스터 된 색인이 뒤죽박죽이 될 수 있습니까?
그렇지 않다면 왜? SQL Server가 NewSequentialId를 사용하고 있음을 알고 있습니까? 그게 어떻게 보상합니까?
그렇지 않다면 다음에 내가 무엇을 삽입 할 것인지 어떻게 알 수 있습니까? 어쩌면 다음 백만 건의 인서트가 3으로 시작 할지도 모릅니다. 아니면 7로 시작 할지도 모릅니다. 어떻게 알 수 있습니까?
아니면 모든 것을 순서대로 유지합니다. 이 경우 한 번의 재부팅으로 성능에 큰 영향을 줄 수 있습니다. (그러면 재부팅에 영향을받지 않는 자체 사용자 정의 NewSequentialId가 필요하다고 생각됩니다.) 맞습니까? 또는 내가 모르고있는 마술이 있습니까?
편집 : GUID는 클러스터 된 인덱스로 사용하는 것이 좋습니다. 위에서 말했듯이 이것이 나쁜 생각이라는 데에는 여러 가지 이유가 있습니다. 이것이 또 다른 이유인지 알아 내려고 노력 중입니다.
"그렇다면 재부팅이 성능에 큰 영향을 줄 수 있습니다." 그래서 당신이 그것을 듣고 싶지 않아도 int IDENTITY()를 사용하려고합니다. – HardCode