SQL Server 2005에서는 대용량 결합이 포함 된 쿼리가 있습니다 (각 테이블의 순서는 수천 행에서 수백만 행 정도이며 평균 테이블은 아마도 10-15 열의 정수 및 날짜 시간에 해당합니다.SQL Server 저장 프로 시저 중간 테이블
쿼리를 더 빠르게 만들려면 하나의 큰 쿼리를 몇 개의 조인을 수행하는 저장 프로 시저로 분할하고 일부 임시 테이블을 만든 다음 임시 테이블을 몇 가지 조인 결과 인 다른 임시 테이블과 조인합니다.
현재 중간 테이블을 저장하기 위해 테이블 변수를 사용하고 있으며 성능 ne는 눈에 띄게 좋습니다. 그러나 생산 과정에서 tempdb에는 IO 병목 현상이있는 것으로 보입니다.
이러한 문제를 해결하는 더 좋은 방법이 있습니까? 내 말은, 테이블 변수를 여기에서 사용하는 거지?
테이블 변수는 TempDB에서 quite a lot of memory을 차지할 수 있습니다.
대규모 프로덕션 환경에서이 표준 테이블을 사용하는 것보다 나은 SQL 코더를 보았습니다. 기본적으로 임시 테이블이지만 정규 테이블로 작성하고 특별한 접두사 또는 접미사를 제공합니다. 이는 실행을 돕기 위해 인덱스를 활용할 수 있다는 부가적인 이점을 제공합니다 (임시 테이블과 마찬가지로).
복잡한 실행의 모든 단계에서 액세스되는 임시 테이블을 사용하거나 임시 테이블을 사용할 수 있으면 메모리 문제를 해결할 수 있습니다.
데이터를 캐시 할 장소로 생각하십시오. 사실, 메인 스토어드 프로 시저가 실행될 때마다이 "캐시"를 업데이트 할 수 있습니다. 적절한 트랜잭션과 잠금을 활용하십시오.
대안을 상상해보십시오 - 저장 프로 시저에서 거대한 테이블 변수를 사용하고 저장 프로 시저가 동시에 10 회 또는 20 회 실행되는 경우 ... 테이블 변수가 더 이상 메모리에 저장되지 않을 수 있습니다.
검색어에 대해 자세히 알려 주실 수 있습니까? 나는 하나의 set-based 쿼리를 여러 개의 임시 테이블과 쿼리로 분할하는 것이 더 빠를 것이라고 생각하지 않습니다. – Matthew
실행 계획은 어떻게 보이나요? –
약 8 개의 조인이 있습니다. 실행 계획은 모든 종류의 병합으로 엄청나 다. 다양한 테이블을 찾고 검색한다. –