SQL Server 2012 Sequence는 Oracle 및 Postgres와 동일한 새로운 기능으로 도입 되었습니다. 서열이 정체성보다 선호되는 곳은 어디입니까? 그리고 왜 시퀀스가 필요한가요?
답변:
여기에서 답을 찾을 수있을 것 같아요
열의 ID 속성을 사용하면 자동 증가 번호 (기본 키로 자주 사용됨)를 쉽게 생성 할 수 있습니다. Sequence를 사용하면 삽입하는 동안 테이블 열에 연결할 수있는 다른 개체가됩니다. ID와 달리 열 값의 다음 번호는 디스크가 아닌 메모리에서 검색됩니다. 따라서 시퀀스가 ID보다 훨씬 빠릅니다. 우리는 다음 예제에서 이것을 볼 것입니다.
그리고 여기 :
시퀀스 : 시퀀스는 SQL Server 커뮤니티에서 수년 동안 요청되었으며이 릴리스에 포함되었습니다. 시퀀스는 일련의 숫자를 생성하는 사용자 정의 개체입니다. 다음은 Sequence를 사용한 예입니다.
그리고 여기에도 :
SQL Server 시퀀스 개체는 SQL 테이블의 ID 열처럼 일련의 숫자를 생성합니다. 그러나 시퀀스 번호의 장점은 시퀀스 번호 개체가 단일 SQL 테이블로 제한되지 않는다는 것입니다.
그리고 msdn에서 사용법과 이것이 필요한 이유에 대해 더 자세히 읽을 수 있습니다 ( 여기 ).
시퀀스는 시퀀스가 생성 된 사양에 따라 숫자 값 시퀀스를 생성하는 사용자 정의 스키마 바인딩 개체입니다. 숫자 값의 시퀀스는 정의 된 간격으로 오름차순 또는 내림차순으로 생성되며 요청에 따라 순환 (반복) 할 수 있습니다. ID 열과 달리 시퀀스는 테이블과 연결되지 않습니다. 응용 프로그램은 다음 값을 받기 위해 시퀀스 개체를 참조합니다. 시퀀스와 테이블 간의 관계는 애플리케이션에 의해 제어됩니다. 사용자 애플리케이션은 시퀀스 객체를 참조하고 여러 행과 테이블에서 값 키를 조정할 수 있습니다.
시퀀스는 CREATE SEQUENCE 문을 사용하여 테이블과 독립적으로 생성됩니다. 옵션을 사용하면 증분, 최대 및 최소 값, 시작 지점, 자동 다시 시작 기능 및 캐싱을 제어하여 성능을 향상시킬 수 있습니다. 옵션에 대한 정보는 CREATE SEQUENCE를 참조하십시오.
행이 삽입 될 때 생성되는 식별 컬럼 값과 달리 애플리케이션은 NEXT VALUE FOR 함수를 호출하여 행을 삽입하기 전에 다음 시퀀스 번호를 얻을 수 있습니다. 번호가 테이블에 삽입되지 않더라도 NEXT VALUE FOR가 호출되면 시퀀스 번호가 할당됩니다. NEXT VALUE FOR 함수는 테이블 정의에서 열의 기본값으로 사용할 수 있습니다. 한 번에 여러 시퀀스 번호 범위를 가져 오려면 sp_sequence_get_range를 사용하십시오.
시퀀스는 정수 데이터 유형으로 정의 할 수 있습니다. 데이터 유형이 지정되지 않은 경우 시퀀스의 기본값은 bigint입니다.
시퀀스와 ID는 모두 자동 번호를 생성하는 데 사용되지만 주요 차이점은 ID는 테이블에 따라 다르며 시퀀스는 테이블과 독립적이라는 것입니다.
자동 번호를 전역 적으로 (여러 테이블에서) 유지해야하는 시나리오가있는 경우 특정 번호 이후 간격을 다시 시작해야하고 성능을 위해 캐시해야하는 경우 여기에 시퀀스가 필요하지 않습니다. 정체.
시퀀스는 ID 열보다 더 많은 유연성을 제공하지만 성능상의 이점이 없다는 것을 알았습니다.
ID를 사용한 성능이 배치 삽입에 시퀀스를 사용하는 것보다 일관되게 3 배 빠르다는 것을 발견했습니다.
약 150 만 행을 삽입했고 성능은 다음과 같습니다.
테이블 기본값을 통해 시퀀스 개체를 사용하는 테이블에 행을 삽입했습니다.
NEXT VALUE for <seq> for <col_name>
또한 select 문에서 시퀀스 값을 지정하려고 시도했습니다.
SELECT NEXT VALUE for <seq>, <other columns> from <table>
둘 다 식별 방법보다 느린 동일한 요인이었습니다. 시퀀스에 기본 캐시 옵션을 사용했습니다.
Arion의 첫 번째 링크에서 참조 된 기사는 행 단위 삽입의 성능을 보여 주며 ID와 시퀀스의 차이는 10,000 개의 삽입에 대해 16.6 초에서 14.3 초였습니다.
캐싱 옵션은 성능에 큰 영향을 주지만 더 많은 볼륨 (+ 1M 행)의 경우 ID가 더 빠릅니다.
utly4life의 의견에 따른 심층 분석 은이 링크 를 참조하십시오 .
alter sequence increment by ...하면 단순히 새 행을위한 공간을 만들고 base + row_number () 또는 실제 값에 대해 무엇이든 사용하여 일괄 삽입 성능을 최적화 할 수 있습니다 .
시퀀스를 가장 잘 사용하는 방법은 ID 열을 바꾸는 것이 아니라 "주문 번호"유형의 필드를 만드는 것입니다.
즉, 주문 번호는 최종 사용자에게 노출되며 이와 함께 비즈니스 규칙이있을 수 있습니다. 고유하게 만들고 싶지만 ID 열을 사용하는 것도 실제로 올바르지 않습니다.
예를 들어, 다른 주문 유형에는 다른 순서가 필요할 수 있으므로 사내 주문과 반대로 인터넷 주문에 대한 순서가있을 수 있습니다.
즉, 시퀀스를 신원의 단순한 대체물로 생각하지 말고 신원이 비즈니스 요구 사항에 맞지 않는 경우 유용하다고 생각하십시오.
최근에는 동일성 대 서열에 대해 고려해야 할 사항이 조금씩있었습니다. 공백없이 정체성을 유지하려는 경우 MSFT가 이제 시퀀스를 제안하는 것 같습니다. ID에 큰 차이가있는 문제가 있었지만 강조 표시된이 문을 기반으로 SQL이 ID를 캐시하고 재부팅 후 해당 번호를 잃었다는 문제를 설명 할 수 있습니다.
서버 재시작 또는 기타 실패 후 연속 값-SQL Server는 성능상의 이유로 ID 값을 캐시 할 수 있으며 데이터베이스 실패 또는 서버 재시작 중에 할당 된 값 중 일부가 손실 될 수 있습니다. 이로 인해 삽입시 ID 값에 간격이 생길 수 있습니다. 간격이 허용되지 않는 경우 애플리케이션은 자체 메커니즘을 사용하여 키 값을 생성해야합니다. NOCACHE 옵션과 함께 시퀀스 생성기를 사용하면 커밋되지 않은 트랜잭션에 대한 간격을 제한 할 수 있습니다.