TechRepublic 무료 SQL Server 뉴스 전달은 각 금요일,담-손 끝에 도움이 될 것입니다 당신상에 숙련된 이 강력한 관계형 데이터베이스 관리 시스템입니다. 오늘 자동으로 구독하십시오!

일반적으로 인정되는 지혜에 대해 저장된 절차(또는 sprocs)기 때문에 SQL 을 최적화할 수 있습와 컴파일,그들은 실행보다 더 빠르게 동등한 SQL 문을 실행에서 QueryAnalyzer(또는 아마도 전달에서부터 프로 같은 웹 페이지 또는 VBprogram). 이것은 어느 정도 사실입니다.

먼저 SQL Server 가 새로운 sproc 로 무엇을하는지 알아야합니다. 생성시 구문을 확인합니다. 오류를 찾지 못하면 시스템 테이블(sysobjects,sysdepends 및 syscomments)에 sproc 를 추가합니다(후자는 sproc 의 본문을 저장합니다). 기본적으로 생성시 sproc 를 컴파일하지 않습니다.

sproc 를 처음 실행하면 SQL Server 가 최적화하고 컴파일합니다. 이것은 SQL Server 가 queryplan 을 고안하여 프로 시저 캐시에 저장하는 경우입니다. 후속 호출에서 SQL 은 캐시를 먼저 찾고 거기에서 sproc 를 찾고이를 컴파일하지 않습니다. Sproc 가 캐시에 없으면 SQL Server 가이를 컴파일하고 캐시에 배치합니다.

WITH RECOMPILE 옵션에 대한 내 경험

a 잠시 뒤로,사용자가 여러 열 중 하나로 검색 할 수있는 검색 페이지를 지원하고있었습니다. 그런 다음 페이지는 sproc 를 호출하여 매개 변수를 전달하여 어떤 열을 검색하는지 나타냅니다. 사례 블록을 사용하여 매개 변수를 조사한 다음 다음 중 하나를 실행했습니다.검색 할 열에 따라 여러 쿼리.

내 alligedlyclever 저장 프로 시저를 테스트하기 시작했을 때 뭔가 잘못되었다는 것을 알았습니다. 이론 상으로는 각 검색의 성능이 거의 같아야하지만 그렇게 된 것은 아닙니다. 내가 수행 할 때다중 검색을 수행 할 때 순서에 관계없이 첫 번째 검색은 빠를 것이고부정적인 검색은 훨씬 느렸다.마지막으로 프로 시저가 처음 호출 될 때 쿼리 계획이 고안되어 캐시에 저장된다는 것을 깨달았습니다. 특정 열에서 검색 한 것처럼 모든 것이 다음과 같이 작동합니다.expected. 그러나 열을 전환 한 순간 성능이 급락했습니다. 왜 이런 일이 일어 났습니까?

내가 수행 한 첫 번째 검색은 캐시에 쿼리 계획과 storedit 을 만들었습니다. 예를 들어,열 OrderDate 에서 검색 중이라고 가정 해보십시오. 면 전환 검색을 회사 열,SQL 것을 맹목적으로 사용하여 캐시 queryplan 검색에 대한 대상 회사 이름을 사용하여 OrderDateindex. 성능이 그렇게 극적으로 급락 한 것은 당연합니다.수정은 매우 간단합니다. 나는 실행 sprocsupplying 다시 컴파일 옵션:

EXEC MySproc_Select '12/31/2004' WITH RECOMPILE

이것은 SQL 서버를 던져 기존의 쿼리 planand 빌드를 다른 하나-그러나 이번만.

AS 키워드 바로 앞에 WITH 재 컴파일을 storedprocedure 에 직접 추가 할 수도 있습니다. 이것은 SQL Server 가 sproc 의 모든 실행에 대한 쿼리 계획을 버리도록 지시합니다.

세 번째 옵션도 있습니다. 각 검색 메소드에 대해 aseparate sproc 을 만들 수 있었고 사례 블록 내에서 어느 것을 실행할 지 결정할 수있었습니다. 그렇게하면 하위 sprocs 와 연결된 쿼리 계획이 SQL 이이를 활용할 수있는 캐시에 남아 있습니다. Sprocssearched 각각이 정확히 하나의 열이므로 다시 컴파일 할 필요가 없습니다.

sql Server 의 storedprocedure 를 최적화하고 컴파일하는 기능은 훌륭하지만 조심하지 않으면 leastexpect 때 물릴 수 있습니다. 이제 문제를 다루는 방법을 알았으므로 아마도 자신의 데이터베이스에 다시 방문하고 싶을 수도있는 상황이있을 것입니다.