성능 동적 SQL 대 임시 테이블

Question

임시 테이블에 기존 테이블을 복사하면 동적 SQL에 비해 성능이 떨어지는 지 궁금합니다. 나는 현재 후자의 스타일로 프로 시저 빌드를 사용하고 있기 때문에 나는이 부탁 해요

CREATE PROCEDURE UsingDynamicSQL 
    (
     @ID INT , 
     @Tablename VARCHAR(100) 
    ) 
AS 
    BEGIN 
     DECLARE @SQL VARCHAR(MAX) 
     SELECT @SQL = 'Insert into Table2 Select Sum(ValColumn) From ' 
       + @Tablename + ' Where ID=' + @ID 
     EXEC(@SQL) 
    END 

    CREATE PROCEDURE UsingTempTable 
     (
      @ID INT , 
      @Tablename Varachar(100) 
     ) 
    AS 
     BEGIN 
      Create Table #TempTable (ValColumn float, ID int) 
      DECLARE @SQL VARCHAR(MAX) 
      SELECT @SQL = 'Select ValColumn, ID From ' + @Tablename 
        + ' Where ID=' + @ID 
      INSERT INTO #TempTable 
        EXEC (@SQL); 
      INSERT INTO Table2 
        SELECT SUM(ValColumn) 
        FROM #TempTable; 
      DROP TABLE #TempTable; 
     END 

:

내가 다음과 같은 두 가지 SQL Server 저장 프로 시저 사이에 다른 성능을 기대해야하는지 궁금 구체적으로 여기서 나는 기존 테이블의 간단한 추출물로 많은 임시 테이블을 만들고이 임시 테이블로 작업하고 있습니다. 임시 테이블을 제거하고 대신 동적 SQL을 사용하여 저장 프로 시저의 성능을 향상시킬 수 있습니까? 필자의 의견으로는 Dynamic SQL 버전이 프로그램에서 훨씬 더 추악하기 때문에 - 우선 임시 테이블을 사용했습니다.

Answer 1

쿼리 최적화 프로그램은 항상 정확히 하나의 행이 있다고 가정하기 때문에 테이블 변수에 성능 문제가 있습니다. 100 개 이상의 행을 갖는 테이블 변수가 있다면, 임시 테이블로 전환 할 것입니다.

exec sp_executesql @sql 대신 EXEC(@sql) 대신 동적 SQL을 사용하면 쿼리 계획이 캐싱되지 않으므로 성능이 저하 될 수 있습니다.

그러나 두 쿼리 모두에서 동적 SQL을 사용하고 있습니다. 유일한 차이점은 두 번째 쿼리는 테이블 변수에 먼저로드 한 다음 최종 테이블에로드하는 불필요한 단계가 있다는 것입니다. 보유한 첫 번째 저장 프로 시저로 이동하지만 sp_executesql로 전환하십시오.

Answer 2

게시 된 쿼리에서 임시 테이블은 여분의 쓰기입니다.
도움이되지 않습니다.

쿼리 계획을 쿼리하는 시간을 정하지 마십시오.
쿼리가 두 개인 경우 쿼리 계획에서이를 알려줍니다.

그리고 테이블 변수와 임시 테이블 사이의 차이가있다
임시 테이블은 빠른 - 쿼리 최적화

이 임시 테이블이 몇 가지 상황에서 도움을 줄 수있는 임시 테이블을 더하지

1. 는 선택의 출력이이 evalu하는 고가의 CTE 함께 참조 어디 한 번만
   실행되도록 한 번
   당신은 출력을 실현 이상을 사용하는 것입니다 거짓의
   사람들은 CTE는 한 번만 실행되는 생각 많은 시간을 ated - 쿼리 최적화 프로그램이 도움이 필요

2. 없고 그것이 단지 구문 당신은 자기 일을
   여러 조건과 큰 테이블에 조인 예
   약관의 일부 행
   행을 필터링하고 또한 당신이 항상 모두를 테스트 할 필요가 다른 사람에 동의 가입 조건의 수

Answer 3

을 줄일 수 #temp에 대한 쿼리의 대부분을 제거 .. 나는 그것을 넣고있다. 여기서 답을하면 더 명확 해집니다.

최종 쿼리에 완벽한 인덱스 설정이있는 경우 임시 테이블로 이동하는 것은 추가 작업 일 수 있습니다.

그렇지 않은 경우 임시 테이블에 대한 사전 필터링이 더 빠르거나 빨라질 수 있습니다.
극단적으로 예측할 수 있습니다. 백만 줄에서 12 줄까지 필터링하면 도움이 될 것입니다.
그러나 그렇지 않으면 시도하지 않고 진정으로 알기 어려울 수 있습니다.

나는 유지 관리 또한 문제이며 많은 동적 SQL은 고려해야 할 유지 관리 비용이라는 데 동의한다.