모든 기본 키가 GUID 인 데이터베이스에서 newid()와 newsequentialid()를 "기본값 또는 바인딩"으로 사용하는 경우의 차이점/의미 및 장단점은 무엇입니까?newid() vs newsequentialid() 차이점/장단점은 무엇입니까?
내가 아는 유일한 차이점은 newid()가 newsequentialid()와 반대되는 새로운 임의의 GUID를 생성한다는 점입니다.이 GUID는 증가 된 방식으로 테이블에있는 마지막 GUID를 기반으로 만듭니다.
DB의 행에 삽입을 수행하면 테이블의 다른 PK와 관련하여 순서대로 삽입됩니다. 일반 GUID를 사용하면 테이블의 어느 위치 에나있을 수 있습니다. newsequentialid()는 항상 테이블의 끝에 추가됩니다.
따라서 인서트 성능이 향상되었습니다.
This site은 두 가지 다른 방법 간의 차이점과 벤치 마크를 설명합니다.
업데이트 - 참조 된 블로그 게시물이 옮겨졌습니다. 링크는 이제 web.archive.org 링크를 나타냅니다. 여기에 키 테이크 아웃은 다음과 같습니다
가장 눈에 띄는는 NEWID 시스템 기능에 필요한 쓰기의 수입니다. 이것은 평균 페이지 밀도가 69 %와 결합되어 잎 수준에서 삽입물의 무작위 분포로 인해 페이지 분할이 발생했다는 증거입니다. 페이지가 채워지 자마자 삽입물을 완성하기 위해 50 % 각각 2 페이지로 분할해야합니다. 페이지 분할로 인해 페이지 밀도가 떨어졌을뿐 아니라 데이터 페이지가 상당히 나뉘어졌습니다 (다음 데이터 페이지가 현재 페이지 옆에 없을 가능성이 99 %입니다). 우리의 테스트에서 페이지 분할에 필요한 빈 페이지의 가장 가능성있는 위치는 행이 삽입되는 위치와 관계없이 테이블 끝에 있습니다. 따라서 순서대로 행을 읽으려면 광범위하게 분산 된 분할 페이지 사이에서 스캔을 계속해야합니다. 따라서 조각화가 쉽지 않습니다. 내가 아는 한
--Stefan 델 마르코
, NEWID() 무작위 순서로 GUID를 생성하고 NEWSEQUENTIALID() 순차적으로 GUID를 생성합니다. NEWSEQUENTIALID()은 테이블의 default 절에서만 사용할 수 있습니다.
이미 작성된 내용에 아무 것도 추가하지 않았습니다. 문제. –
제 생각에 SQL 인스턴스가 실행되면 NEWSEQUENTIALID GUID는 임의의 값으로 초기화됩니다. 그런 다음 운영 기간 동안 GUID는 중앙 GUID에서 증가되며 테이블에 대해 생성 된 마지막 GUID를 조사하지 않습니다.
이렇게하는 것이 인덱스에 있습니다. 완전한 무작위 GUID는 인덱스를 너무 많이 조각화하므로 순차 GUID는 삽입 및 인덱싱 성능에 좋습니다. – Todd
[Microsoft 상태] (https://msdn.microsoft.com/da-dk/library/ms189786.aspx)는 호스트 시스템이 마지막으로 시작된 이후 생성 된 마지막 GUID와 관련하여 순차적입니다. –
순차 키 (ID, 시퀀스 및 NEWSEQUENTIALID)와 비 순차 키 (NEWID 또는 맞춤 임의 키 생성기)와 관련하여 고려해야 할 몇 가지 측면이 있습니다.
순차 키로 시작하여 모든 행이 색인의 오른쪽 끝에 있습니다. 페이지가 가득 차면 SQL Server는 새 페이지를 할당하고 채 웁니다. 결과적으로 인덱스에서 조각화가 적어 지므로 읽기 성능에 도움이됩니다. 또한 단일 세션에서 데이터가로드되고 데이터가 단일 드라이브 또는 소수의 드라이브에있는 경우 삽입이 더 빠를 수 있습니다.
그러나 스핀들이 많은 하이 엔드 저장소 하위 시스템에서는 상황이 다를 수 있습니다.여러 세션에서 데이터를로드 할 때 페이지 리프치 경합 (래치는 인덱스 페이지 레벨의 링크 된 목록의 가장 오른쪽 페이지에 대해 데이터베이스 페이지에 대한 액세스를 동기화하는 데 사용되는 오브젝트 임)로 끝납니다. 이 병목 현상으로 인해 스토리지 서브 시스템의 전체 처리량이 사용되지 않습니다. 순차 키를 사용하고 숫자 키를 사용하려는 경우 유형의 최저 값부터 시작하여 항상 전체 범위를 사용할 수 있습니다. 예를 들어 INT 유형에서 1로 시작하는 대신 -2,147,483,648부터 시작할 수 있습니다.
NEWID 또는 사용자 정의 솔루션으로 생성 된 임의의 키와 같은 비 순차 키를 고려하십시오. 이미 전체 페이지로 행을 강제 실행하려고하면 SQL Server는 기본 페이지 분할을 수행합니다. 새 페이지를 할당하고 행의 절반을 원본 페이지에서 새 페이지로 이동합니다. 페이지 분할에는 비용이 들며 인덱스 조각화가 발생합니다. 인덱스 조각화는 읽기 성능에 부정적인 영향을 줄 수 있습니다. 그러나 삽입 성능면에서 스토리지 서브 시스템에 많은 스핀들이 포함되어 있고 다중 세션에서 데이터를로드하는 경우 분할이 발생하더라도 순차 순서보다 무작위 순서가 실제로 좋을 수 있습니다.
인덱스의 오른쪽 끝에 핫 스팟이 없기 때문에 스토리지 서브 시스템의 사용 가능한 처리량을 향상시킬 수 있습니다. 이 전략을 보여주는 벤치 마크의 좋은 예는 Thomas Kejser의 블로그 http://blog.kejser.org/2011/10/05/boosting-insert-speed-by-generating-scalable-keys/에 있습니다.
출처 : 쿼리 마이크로 소프트 SQL Server® 2012 시험 70-461 교육 키트
응? 연속적으로 생성되는 경우 생성 된 GUID가 실제로 GUID와 비슷한 형식이 아닌 고유 한 GUarneted가 될 수 있습니까? – Justin
@Justing - GUID가 고유하다는 보증은 없습니다. –
링크가 휘발성이며 ... Fotia now 404s가 대답의 링크. –