저장 프로 시저와 원시 쿼리의 효율성

이 토론의 양 측면에서 많은 내용을 읽었습니다. 원시 쿼리보다 저장 프로 시저 만 사용하면 성능이 크게 향상됩니까? 특히 SQL Server에 관심이 있지만 모든 데이터베이스에 관심이 있습니다.

SQL Server 2008 이상에서는 그렇지 않지만 여전히 있습니다. 실행 계획 캐시와 SQL Server는 전송 된 쿼리를 자동으로 매개 변수화 할 수 있습니다. 저장 프로 시저 (동적 SQL이없는 쿼리)를 사용할 때는 쿼리가 이미 매개 변수화되어 SQL Server가 계획이 계획 캐시에 이미 저장되어 있으므로 쿼리가 실행될 때 각 쿼리에 대한 계획을 생성해야합니다.

저장 프로 시저를 사용할 때 사라지는 보안 문제 (동적 SQL, 최소 권한 등)도 잊지 마십시오.

앱이 기본 테이블에 대해 동적 SQL을 사용하여 테이블의 데이터를 선택, 삽입, 업데이트 및 삭제하는 경우 응용 프로그램은 모든 해당 개체에 직접 권한을 가져야합니다. 따라서 누군가 누군가 SQL 인젝션을 사용하여 서버에 액세스하면 해당 테이블의 모든 데이터를 쿼리, 변경 또는 삭제할 수있는 권한이 있습니다.

스토어드 프로 시저를 사용하는 경우 스토어드 프로 시저가 리턴 할 정보 만 리턴하여 스토어드 프로 시저를 실행할 권한 만 있습니다. 빠른 삭제 문을 발행하고 모든 것을 날려 버리는 대신 데이터를 삭제하는 데 사용할 수있는 절차를 파악한 다음 절차를 사용하여 수행하는 방법을 알아 내야합니다.

SQL 인젝션이 데이터베이스를 침입하는 가장 쉬운 방법이라는 점을 고려하면 이는 일종의 중요합니다.

Denny의 답변에 대한 부록으로, 단일 또는 저용량의 임시 실행 계획에서 상당한 버퍼 풀 메모리가 낭비되는 시스템을 찾는 것은 드문 일이 아닙니다.

최악의 경우, 최근 8GB가 인스턴스, 3GB 계획 캐시, 2.5GB 단일 사용 계획에 할당되었습니다. 이들 중 대부분은 SQL2005이므로 임시 워크로드 최적화 설정을 시도하는 옵션이 아닙니다.

원시 쿼리에 대한 프로 시저에 대한 정당화에 성능을 포함시키는 것이 확실히 어려워지고 있습니다. 저에게있어 가장 강력한 주장 중 하나는 "절차를 사용하면 성능 문제가 발생할 때 도움을주는 것이 훨씬 쉽다"는 것입니다. 동적 / linq / orm 인터페이스는 튜닝을 방해하지 않지만 옵션을 심각하게 제한 할 수 있습니다.

SQL Server는 동일한 방식으로 저장 프로 시저와 임시 SQL을 캐시하고 최적화합니다. 예를 들어이 절차는 다음과 같습니다.

create procedure dbo.TestSB(@id int) as select * from Orders where id = @id

다음과 동일하게 최적화되고 캐시됩니다.

select * from Orders where id = @id

그러나 하드 코딩 된 값으로 인해 다음과 같은 임시 SQL을 효과적으로 캐시 할 수 없습니다.

select * from Orders where id = 42

성능은 동일하지만 저장 프로 시저를 사용해야하는 충분한 이유가 있습니다. 저장 프로시 저는 DBA와 응용 프로그램 개발자를 명확하게 구분합니다. 귀중한 데이터와 끊임없이 변화하는 프로그램 사이에 추가 방어 계층을 두는 것이 좋습니다. :)