단일 행 INSERT… SELECT는 별도의 SELECT보다 훨씬 느립니다.

1에서 400까지 400 개의 행이있는 다음 힙 테이블이 제공됩니다.

DROP TABLE IF EXISTS dbo.N;
GO
SELECT 
    SV.number
INTO dbo.N 
FROM master.dbo.spt_values AS SV
WHERE 
    SV.[type] = N'P'
    AND SV.number BETWEEN 1 AND 400;

다음 설정 :

SET NOCOUNT ON;
SET STATISTICS IO, TIME OFF;
SET STATISTICS XML OFF;
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

다음 SELECT문장은 약 6 초 안에 완료됩니다 ( demo , plan ).

DECLARE @n integer = 400;

SELECT
    c = COUNT_BIG(*) 
FROM dbo.N AS N
CROSS JOIN dbo.N AS N2
CROSS JOIN dbo.N AS N3
WHERE 
    N.number <= @n
    AND N2.number <= @n
    AND N3.number <= @n
OPTION
    (OPTIMIZE FOR (@n = 1));

_{참고 : @이 OPTIMIZE FOR조항은 다양한 이유로 발생할 수있는 카디널리티 오도를 포함하여 실제 문제의 필수 세부 사항을 캡처하는 현명한 크기의 재현을 생성하기위한 것입니다.}

단일 행 출력이 테이블에 기록되면 19 초가 소요됩니다 ( demo , plan ).

DECLARE @T table (c bigint NOT NULL);

DECLARE @n integer = 400;

INSERT @T
    (c)
SELECT
    c = COUNT_BIG(*) 
FROM dbo.N AS N
CROSS JOIN dbo.N AS N2
CROSS JOIN dbo.N AS N3
WHERE 
    N.number <= @n
    AND N2.number <= @n
    AND N3.number <= @n
OPTION
    (OPTIMIZE FOR (@n = 1));

실행 계획은 한 행 삽입과 동일하게 나타납니다.

여분의 시간은 모두 CPU 사용량으로 소비되는 것 같습니다.

왜 INSERT진술이 너무 느려 집니까?

SQL Server는 행 수준 잠금을 사용하여 루프 조인의 안쪽에있는 힙 테이블을 검색하도록 선택합니다. 전체 스캔은 일반적으로 페이지 레벨 잠금을 선택하지만 테이블 크기와 술어의 조합은 스토리지 엔진이 행 잠금을 선택한다는 것을 의미합니다. 이는 가장 저렴한 전략 인 것으로 보입니다.

카디널리티 오정은 의도적으로 OPTIMIZE FOR힙이 옵티마이 저가 예상하는 것보다 여러 번 스캔됨을 의미 하며 스풀을 정상적으로 도입하지 않음을 의미합니다.

이러한 요소 조합은 성능이 런타임에 필요한 잠금 수에 매우 민감하다는 것을 의미합니다.

이 SELECT명령문 은 커밋되지 않은 데이터를 읽을 위험이없고 행 외부 데이터가 없을 때 행 수준 공유 잠금을 건너 뛸 수 있도록 (인 텐트 공유 페이지 수준 잠금 만 수행) 최적화 할 수 있습니다 .

이 INSERT...SELECT명령문은이 최적화의 이점을 얻지 않으므로 두 번째 경우에는 의도 공유 페이지 레벨 잠금과 함께 수백만 개의 RID 잠금이 초당 해제됩니다.

엄청난 양의 잠금 활동이 추가 CPU 및 경과 시간을 설명합니다.

가장 자연스러운 해결 방법은 옵티 마이저 (및 스토리지 엔진)가 적절한 카디널리티 추정치를 확보하여 올바른 선택을 할 수 있도록하는 것입니다.

실제 사용 사례에서 실용적이지 않으면 INSERTand SELECT문을 분리하여 결과를 SELECT변수로 보유 할 수 있습니다 . 이를 통해 SELECT명령문은 잠금 건너 뛰기 최적화의 이점을 얻을 수 있습니다.

공유 잠금을 사용하지 않거나 잠금 에스컬레이션이 신속하게 수행되도록하여 격리 수준을 변경할 수도 있습니다.

최종 관심 지점으로, SELECT문서화되지 않은 추적 플래그 8691을 사용하여 스풀을 사용하도록하여 쿼리를 최적화 된 경우 보다 훨씬 빠르게 실행할 수 있습니다 .