sp_executesql은 언제 쿼리 계획을 새로 고치나요?

DBA가 아니기 때문에 순진함을 용서해야하지만 시간이 지남에 따라 데이터베이스 변경 및 저장 프로 시저의 통계를 최신 통계로 쿼리 계획을 최신 상태로 유지하기 위해 다시 컴파일해야한다는 것을 이해합니다.

나는의 최신 통계에 대해 다시 컴파일 내 데이터베이스에 저장 프로 시저가 가정 일부 코드에서 저장 프로 시저에 라이닝과 그것을 포장의 의미 무엇인가, 일정한 간격을 sp_executesql문은? 프로 시저 재 컴파일의 일부로 발생했던 쿼리 계획의 새로 고침이 손실됩니까?

이 변경을 수행하기 전에 고려해야 할 사항 (사용 권한 이외의 다른 항목)이있는 경우 귀하의 통찰에 감사드립니다.

MSDN에서 이것을 읽었습니다.

새 Transact-SQL 문자열을 기존 실행 계획과 일치시키는 SQL Server 쿼리 최적화 기능은 특히 복잡한 Transact-SQL 문에서 문자열의 텍스트에서 끊임없이 변경되는 매개 변수 값으로 인해 방해를받습니다.

따라서 인라인 및 랩핑하려는 저장 프로 시저에 sp_executesql실제로 일부 매개 변수가 포함되어 있다고 가정하면 실행 계획이 캐시되어 있지만 SQL Server에서 찾기 및 재사용하기가 더 어려워지고 있습니까?

MSDN의 라인은 다음과 같이을 사용하는 것에 대해 이야기하고 있습니다 EXEC().

SET @sql = 'SELECT foo FROM dbo.bar WHERE x = ''' + @x + ''';';
EXEC(@sql);

필자의 테스트에서 최신 버전의 SQL Server는 여전히 이와 같은 계획을 재사용 할 수 있지만 버전과 같은 다른 변수가있을 수 있습니다 (예 : WHERE특정 매개 변수의 존재에 따라 조건부 절 을 추가 하는 경우) 다른 계획을 생성합니다).

sp_executesql매개 변수 값 을 사용 하면 일반 SQL과 마찬가지로 매개 변수 스니핑 문제가 여전히 발생할 수 있지만 SQL Server가 계획을 다시 사용할 수 있는지 여부와는 관련이 없습니다. sp_executesql직접 쿼리를 다시 컴파일하는 변수를 다시 컴파일하지 않는 한이 계획은 전혀 사용하지 않은 것처럼이 계획을 계속해서 다시 사용하게 되며,이 경우에도 다시 컴파일됩니다 (본질적으로 SQL Server는 그렇지 않습니다). "sp_executesql에서 실행되었지만이 작업은 실행되지 않았습니다."

SET @sql = N'SELECT foo FROM dbo.bar WHERE x = @x;';
EXEC sp_executesql @sql, N'@x VARCHAR(32)', @x;

또한 동적 SQL에 대한 보호 기능이 내장되어 있으며 문자열 구분 기호로 인해 작은 따옴표를 두 배로 늘릴 염려가 없습니다. 나는 이것에 대해 블로그에 올렸다 .

계획 재사용 및 / 또는 매개 변수 스니핑에 문제가있는 OPTION (RECOMPILE)경우 OPTIMIZE FOR, optimize for ad hoc workloads및을 살펴보십시오 simple/forced parameterization. 최근 웹 캐스트에 대한 응답으로 비슷한 질문을 몇 가지 해결했습니다.

http://sqlperformance.com/performance-palooza

요점은 : 사용을 두려워하지 말고 필요할 sp_executesql때만 사용하고 실제 성능 문제가있을 때 과도하게 최적화하는 데만 에너지를 소비하십시오. 동적 SQL을 사용할 이유가 없기 때문에 위의 예는 끔찍한 예입니다. 합법적 인 사용 사례가 있다고 가정 하여이 답변을 작성했습니다.

sp_executesql을 통해 실행되는 쿼리는 sp_executesql을 통해 실행되지 않는 일반 쿼리와 동일한 실행 계획 규칙을 따릅니다. 쿼리 텍스트가 변경되면 새 계획이 작성됩니다. 매개 변수 사용자로 인해 텍스트가 변경되지 않으면 계획이 재사용됩니다. 통계가 업데이트되면 계획이 만료되고 다음에 쿼리가 실행될 때 새로운 계획이 생성됩니다.