내 저장 프로시저가 SqlCommand보다 SSMS에서 더 빠르게 실행되는 이유는 무엇입니까?

저장 프로시저의 성능 차이: SqlCommand와 SSMS

저장 프로시저의 실행 시간은 SQL Server Management Studio( 매개 변수 스니핑이 없는 경우에도 SSMS) 및 System.Data.SqlClient.SqlCommand. 근본 원인은 각 실행 환경에서 활성화되는 다양한 SET 옵션에 있을 수 있습니다.

SQL Server Profiler를 사용하여 SSMS가 .NET Sql 클라이언트 데이터 공급자가 생략하는 여러 SET 명령을 실행하는 것으로 나타났습니다. 이러한 SET 옵션은 쿼리 계획 및 성능에 영향을 미칠 수 있습니다. 이 경우 범인으로 등장한 중요한 SET 옵션 중 하나는 다음과 같습니다.

SET ARITHABORT ON

이 SET 옵션을 활성화하면 잠재적으로 오버플로, 0으로 나누기 또는 기타 예외 조건이 발생할 수 있는 산술 연산이 포함된 쿼리가 발생합니다. 조기 중단됩니다. 이 동작은 예외 발생을 허용하는 SET ARITHABORT OFF의 기본 설정과 다릅니다.

결과적으로 저장 프로시저의 실행 계획 및 성능은 SET ARITHABORT 옵션에 의해 영향을 받을 수 있습니다. 저장 프로시저 내의 산술 연산에 이 설정이 적용되는 경우 SSMS와 SqlCommand 간의 실행 시간에 차이가 발생할 수 있습니다.

이 문제를 완화하려면 애플리케이션에서 사용하는 SET 옵션을 주의 깊게 검토하는 것이 좋습니다. SQL Server에 연결됩니다. SSMS에서 사용되는 것과 동일한 SET 옵션을 SqlCommand에서 사용하면 성능 불일치를 피할 수 있습니다. 또한 SQL Server 프로파일러를 활용하여 활성 SET 옵션을 식별하는 것은 유용한 디버깅 기술입니다.

연결 문자열 매개변수, 트랜잭션 동작, MARS(Multiple Active Result Set) 설정과 같은 다른 요소도 성능에 영향을 미칠 수 있습니다. 잠재적 기여 요인으로 간주되어야 합니다.

위 내용은 내 저장 프로시저가 SqlCommand보다 SSMS에서 더 빠르게 실행되는 이유는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!