대량 삽입을하고 있지만 실제 테이블에 삽입하기 전에 몇 가지 검사를해야합니다. 그래서 현재 임시 테이블에 삽입하고 있지만 표를 선언하는 것이 가능하다는 것을 알았습니다. 그래서 제 질문은 - 어느 것이 더 빠릅니까? CREATE 또는 DECLARE. 테이블에는 여러 개의 SELECTS가 완료되며 약 200,000 개의 레코드가 포함됩니다.SQL 효율성 - 어느 것이 더 빠릅니까?
DECLARE @tbl1 TABLE
(
col1 VARCHAR(10)
)
또는
CREATE TABLE tbl1
(
col1 VARCHAR(10)
)
마지막으로,이 선언 된 테이블을 변경할 수 있습니까?
진심으로 감사드립니다.
@tbl 테이블 바는 메모리에 저장되지만 메모리 압력이 높으면 will spill into tempdb입니다.
DDL은 @tbl 바스에서 허용되지 않으며, 의도적으로 (인덱스, 통계 등은 없음) 허용됩니다.
정규 테이블은 연결된 데이터베이스에 생성됩니다.
성능은 모두 SQL Server 구성 방법과 tempdb에 할당 된 리소스에 따라 다릅니다.
일반적으로 많은 수의 레코드를 처리 할 때 테이블 바를 통한 통계 및 풍부한 인덱싱을 허용하는 #table과 같은 연결 당 임시 테이블을 사용할 것입니다.
때때로 영구적 인 스테이징 테이블을 갖는 것이 좋지만 이러한 솔루션을 사용하면 동시성에주의해야합니다.
유일한 방법은 여기에 확실한 대답이
테이블 변수가 항상 tempdb에 I/O를 수행한다는 것이 확실합니다. 글쎄요, 제가 읽은 대부분의 소스는 SQL 2008에서 변경되었는지 확실하지 않습니다. –
@Adam은 SQL Server 스토리지 팀에서 게시 한 링크를 참조하십시오. 테이블 vars는 항상 tempdb에 IO를 수행하지만 메모리 압력이 낮 으면 메모리의 내용을 수행 할 수 있습니다. 그들은 현재 DB에서 IO를 수행하지 않습니다. –
정도면 충분합니다. 그것은 재미있는 읽을 거리였습니다. 이것은 내가 항상 행동을 lol 무엇인지 생각 나게하는 구글에게 보이는 것입니다 –
이 설정 큰 샘플 데이터를 두 개의 샘플 스크립트를 작성하고를 사용하는 (꽤 자주 생산 데브을 다르게 구성됩니다 참고 염두) 환경에서 측정되어 얻을 수 있습니다 실행 계획. 내가 제안 할 수있는 유일한 방법은 범위를 벗어날 때 테이블 변수를 관리하는 것이 쉬울 것이라는 점이지만 영구적 인 준비 테이블은 한 번만 생성하면됩니다. –