보기에서 임시 테이블에 삽입하는 것이 매우 느립니다.

Question

내 쿼리에서 다른 임시 테이블을 사용하고 있습니다. 아래 쿼리를 실행할 때

select * from myView 

실행하는 데 단지 5 초 밖에 걸리지 않습니다. 제가

select * into #temp from myView 

을 실행할 때

는 있지만 (상기 질의보다 10 배 이상) 50 초 걸린다.

SQL Server 2000에서 SQL Server 2008 R2로 마이그레이션했습니다. SQL 2000 이전에는 쿼리가 모두 같은 시간이 걸렸지 만 SQL Server 2008에서는 실행하는 데 10 배 이상 걸립니다.

Answer 1

네, 명령 실행 계획을 확인해 보겠습니다. 정렬이나 오버 헤드에 오버 헤드가있을 수 있습니다.

Answer 2

나는 tempdb 데이터베이스가 문제가 있다고 생각합니다. I/O, 조각화, RAID 고장 등이있을 수 있습니다.

Answer 3

임시 테이블에 삽입하기 전에 select * from myView order by col1과 같이 select 문에 order by 절이 있습니까? by by가 있으면 임시 테이블에 삽입하는 횟수가 많이 줄어 듭니다. 이런 경우, 삽입 후

select * from #temp order by col1 

Answer 4

오래된 질문에 의해 순서를 적용

select * 
into #temp 
from myView 

처럼 일어난 후 삽입이 발생 주문하면서 의해 순서를 제거 할 수 있지만 그래도 난 (비슷한 문제를 가지고로 SQL Server 2014에서) 그리고 쉽게 사용할 수있는 리소스에서 보지 못한 방식으로이를 해결했습니다. 다른 사람에게 도움이되기를 기대하면서 공유 할 것이라고 생각했습니다. 나는 SELECT..INTOSELECT로 변환 할 때 (이 시점에서 내가 쿼리를 중지) 내가 만든했던 뷰가 전체 결과 집합을 반환 21 초 복용했지만, 10 + 분 정도 걸릴 것입니다 :

나는 비슷한 상황이 있었다 조인이없고 술어가없는 간단한 것이 었습니다. 내 직감은 옵티마이 저가 추가 인스턴스 INTO을 기반으로 원래 계획을 변경하고 있었기 때문에 첫 번째 인스턴스 에서처럼 데이터 세트를 가져 오지 않고 INSERT을 수행하지만 그 대신 매우 최적 이하로 실행되도록 변경했습니다.

먼저 OPENQUERY을 시도하여 결과 집합을 먼저 생성 한 다음 임시 테이블에 삽입하려고했습니다. 이 방법의 총 작동 시간은 23 초였으며 원래의 시간은 원래 SELECT 시간에 훨씬 가깝습니다. 그런 다음 원래의 SELECT..INTO 쿼리로 돌아가 OPTION (FORCE ORDER) 힌트를 추가하여 OPENQUERY 동작을 복제하려고 시도했습니다. 이것은 트릭을 한 것 같았고 시간은 OPENQUERY 방법으로 23 초가되었습니다.

나는 쿼리 계획을 비교하는 순간에 충분한 시간을 가지고 있지 않지만,이 문제로 실행하면 신속하고 더러운 옵션으로, 당신은 시도 할 수 있습니다 :

select * into #temp from myView option (force order);