T-SQL의 임시 테이블에서 인덱스를 최대한 활용

Question

저장 프로시저 내에서 임시 테이블을 만들고 여기에 인덱스를 한두 개 추가하여 이에 대한 추가 문의 성능을 향상시키려는 경우 가장 좋은 방법은 무엇입니까?사이베이스는 말한다 이것:

"인덱스가 생성될 때 테이블에는 데이터가 포함되어야 합니다.임시 테이블을 생성하고 빈 테이블에 인덱스를 생성하는 경우 Adaptive Server는 히스토그램, 밀도 등의 열 통계를 생성하지 않습니다.인덱스를 생성한 후 데이터 행을 삽입하면 최적화 프로그램의 통계가 불완전해집니다."

그러나 최근 동료는 임시 테이블을 실제로 사용하는 저장 프로시저와 다른 내장 프로시저에서 임시 테이블과 인덱스를 생성하면 Adaptive Server 옵티마이저가 ~ 할 것이다 그것들을 활용할 수 있습니다.

전반적으로 나는 가치를 거의 추가하지 않는 래퍼 절차를 별로 좋아하지 않기 때문에 실제로 이것을 테스트하지는 않았지만 다른 사람이 있는지 확인하기 위해 질문을 게시해야겠다고 생각했습니다. 접근이나 조언?

Answer 1

몇 가지 생각:

• 임시 테이블이 너무 커서 인덱스를 작성해야 하는 경우 문제를 해결하는 더 좋은 방법이 있습니까?

• 다음 형식의 최적화 힌트를 제공하여 인덱스를 사용하도록 강제할 수 있습니다(인덱스가 테이블에 액세스하는 올바른 방법이라고 확신하는 경우).

  SELECT * 
  FROM   #table (index idIndex) 
  WHERE  id = @id
  

일반적인 성능 팁에 관심이 있는 경우 이에 대한 몇 가지 다른 질문에 대해 다음과 같이 답변해 드립니다.

• 즐겨찾는 성능 튜닝 요령
• 특정 쿼리에 대해 테이블을 어떻게 최적화합니까?

Answer 2

임시 테이블에 데이터를 넣은 후 인덱스를 추가할 때 어떤 문제가 있나요?

염두에 두어야 할 한 가지는 동시에 실행될 수 있는 프로시저의 다른 인스턴스에 대한 인덱스의 가시성입니다.

나는 이러한 종류의 임시 테이블(및 인덱스)에 guid를 추가하여 충돌이 발생하지 않도록 하는 것을 좋아합니다.이 접근 방식의 또 다른 이점은 임시 테이블을 실제 테이블로 만들 수 있다는 것입니다.

또한 이러한 임시 테이블의 데이터를 쿼리해야 하는지 확인하세요. 한 번 이상 그렇지 않으면 인덱스 생성 비용이 선택에 대한 이점보다 커집니다.

Answer 3

Sybase에서 임시 테이블을 생성한 다음 이를 하나의 프로세스에서 사용하는 경우 선택에 대한 계획은 테이블의 대략 100개 행을 사용하여 구축됩니다.(계획은 테이블이 채워지기 전에 프로시저가 시작될 때 작성됩니다.) 이로 인해 임시 테이블이 "100개 행"에 불과하므로 테이블이 스캔될 수 있습니다.다른 proc을 호출하면 Sybase가 실제 행 수를 사용하여 선택에 대한 계획을 작성하게 되며, 이를 통해 최적화 프로그램은 사용할 더 나은 인덱스를 선택할 수 있습니다.이 접근 방식을 사용하여 상당한 개선을 보았지만 때로는 차이가 없기 때문에 데이터베이스에서 테스트해 보세요.