2014-07-23 2 views
0

나는 온라인으로 몇 가지 조사 후, 나는이 개 질문이 생겨 가지고, 내 저장 프로 시저를 가속화하기 위해 노력하고있어 :이 질문에

질문 # 1 : 나는 지역에 모든 매개 변수를 전송해야합니다 변하기 쉬운?

CREATE PROCEDURE TEST(@test nvarchar(MAX)) 
AS 
    SET NOCOUNT ON; 

    SELECT * FROM my_table 
    WHERE my_column = @test; 

VS

일반적인 경우
CREATE PROCEDURE TEST(@test nvarchar(MAX)) 
AS 
    SET NOCOUNT ON; 
    Declare @locTest nvarchar(MAX); 
    Set @locTest = @test; 

    SELECT * FROM my_table 
    WHERE my_column = @locTest; 

은, 위의 어느 빠르게 실행하는 것입니다?

질문 # 2 : 저장 프로 시저 내에서 간단한 한 줄의 쿼리를 실행하거나 직접 쿼리를 작성하기 위해 저장 프로 시저를 호출해야합니까?

CREATE PROCEDURE TEST(@test nvarchar(MAX), @username nvarchar(MAX)) 
AS 
    SET NOCOUNT ON; 

    INSERT INTO AuditTable 
    Values(NEWID(), @test, @username, getdate()); 

VS

CREATE PROCEDURE TEST(@test nvarchar(MAX),@username nvarchar(MAX)) 
AS 
    SET NOCOUNT ON; 

    EXEC InsertAudit @value = @test, @username = @username; 

CREATE PROCEDURE InsertAudit(@value nvarchar(MAX), @username nvarchar(MAX)) 
AS 
    SET NOCOUNT ON; 

    INSERT INTO AuditTable 
    Values(NEWID(), @value, @username, getdate()); 

이 사람은 분명있을 수 있습니다하지만, 난 여전히 위의 빠른 일반적인 경우에 실행하는 것입니다 어느 있는지 확인하려면.

그리고이 제목은 꽤 유익하지는 않지만 더 좋은 것은 아닙니다.

감사합니다.

+4

(1) No. (2) No. –

+2

저장 프로 시저의 감사 테이블로 보내지 마십시오. 감사는 데이터 inteh 테이블이 변경 되더라도 발생해야하므로 반드시 트리거되어야합니다. 또한 여러 레코드 삽입/업데이트를 처리하도록 작성되므로 값 절이 적절하지 않습니다. – HLGEM

+1

삽입 할 데이터베이스의 열이 nvarhar (max)에 있습니까? 매개 변수는 삽입 할 열의 데이터 유형과 일치해야합니다. 모든 열이 nvarchar (max) 인 경우 최대한 빨리 색인을 생성 할 수 없도록 재 설계해야하며 인덱싱하지 않으면 항상 나쁜 성능을 보입니다. – HLGEM

답변

1

1 : 일반적으로 거의 동일하게 실행됩니다. 로컬 변수를 사용하여 매개 변수를 대체하는 인수는 매개 변수 스니핑으로 인해 발생하는 잘못된 캐시 된 실행 계획을 제거합니다. 귀하의 예를 들어, "B"를 선택합니다.

2 : 단일 쿼리 만 처리하기 위해 중첩 저장된 proc을 만들지는 않겠습니다. 성능 차이는 미미할 것이며 유지 관리 번거 로움을 초래할 것입니다. 따라서 귀하의 예에서는 "A"를 선택합니다.

2

질문에 대답하기 위해 로컬 변수를 사용하면 매개 변수 스니핑으로 인해 성능이 향상 될 수 있습니다. 모든 성능 튜닝과 마찬가지로 특정 데이터베이스의 디자인과 데이터의 양과 유형뿐만 아니라 인덱싱과 같은 다른 요소의 영향을받을 수 있습니다. 따라서이 변경 작업을 수행하면 작업 속도가 현저하게 빨라질 수도 빨지 않을 수도 있습니다 . 색인 부족과 같은 것이 문제를 일으키는 경우이 변경으로 문제가 해결되지 않습니다.

두 번째 저장된 proc에서 수행되는 작업이 많은 procs에 추가해야하는 경우, 그렇다면 별도의 proc이어야하므로 버그가있는 경우 한 곳에서만 수정하면됩니다 . 그러나 proc에서 감사 테이블에 삽입하는 것이 적절한 상황은 없습니다. 이러한 조건은 조건에서 이어야하며 트리거를 통해서만 수행해야합니다. 그렇지 않으면 감사해야 할 많은 레코드 변경 사항이 누락됩니다. 나는 이것을 너무 강하게 말할 수는 없으며, 감사는 애플리케이션이나 저장된 proc로부터 결코 적절하지 못하다. 못!!!!! 종종 감사에서 찾아야 할 사항은 응용 프로그램 외부에서 일어난 무단 변경 때문입니다.

관련 문제