Sql 서버 쿼리 성능

나는 값 비싼 쿼리 목록에서 (항상 어떤 식 으로든) 끊임없이 바쁜 데이터베이스에 저장 프로 시저를 가지고 있습니다. 쿼리는 매우 간단합니다. 테이블의 기본 키인 단일 매개 변수 (@ID, int)를 사용하고 해당 ID와 일치하는 레코드를 선택합니다. 기본 키는 클러스터 된 인덱스가있는 ID 필드이므로이를 더 이상 최적화하는 방법에 관해서는 부족합니다.Sql 서버 쿼리 성능

CREATE PROCEDURE [dbo].[P_Call_Get] 

    @ID int = null 

AS 

    select ID, 
     AppID, 
     AgentID, 
     AgentLogin, 
     Ext, 
     VDN, 
     VDNName, 
     Skill, 
     SkillName, 
     CallFrom, 
     TelNoFrom, 
     ParentCallID, 
     CallStart, 
     ACWStart, 
     CallEnd, 
     Outcome, 
     StageID, 
     TxTo, 
     TxSuccess, 
     ServiceID, 
     DiallerID, 
     CRC, 
     TSCallID, 
     CallDirection, 
     [Manual], 
     CallBackAgent, 
     CallBackDateTime, 
     Notes 
    from P_Call 
    where (ID = @ID or @ID is null)

확실하지 실행 계획을 게시 할 수있는 최선의 방법을 다음과 같이 쿼리는 - 그것은 보여줍니다 모든 작업의 100 %

출처

2010-05-07 Macros

코드를 게시 할 수 있습니까? –

쿼리 및 실행 계획을 게시 할 수 있습니까? –

가장 비싸다고 말하면 얼마나 많은 읽기가 있었습니까? 얼마나 자주 호출됩니까? –

나는 where (ID = @ID or @ID is null)을 사용하여 하위 최적 계획을 얻고 있다고 생각합니다. @Id가 null이 아닌 경우 직접 조회하고 계획에 나타나는 검색보다는 찾기를 얻도록 2 개의 개별 쿼리로 나눕니다. 그래서 전 이렇게

DBCC DROPCLEANBUFFERS 
DBCC FREEPROCCACHE

: 당신은 아마

select ID, 
    AppID, 
    AgentID, 
    AgentLogin, 
    Ext, 
    VDN, 
    VDNName, 
    Skill, 
    SkillName, 
    CallFrom, 
    TelNoFrom, 
    ParentCallID, 
    CallStart, 
    ACWStart, 
    CallEnd, 
    Outcome, 
    StageID, 
    TxTo, 
    TxSuccess, 
    ServiceID, 
    DiallerID, 
    CRC, 
    TSCallID, 
    CallDirection, 
    [Manual], 
    CallBackAgent, 
    CallBackDateTime, 
    Notes 
from P_Call

출처

2010-05-07 11:29:00

네, 맞습니다. +1 – Quassnoi

2 개의 쿼리로 나누는 것이 정확히 이루어졌습니다. 이제는 실행 계획에서 검색보다는 검색을 수행합니다. 어느 정도의 선택 기준으로 검색하는 SP의 수에서이 접근 방식을 사용했기 때문에 어느 정도 나를 놀라게합니다. 더 나은 접근 방식에 대해 물어 보려고 했었지만 이것들을 최적화하는 것이 별개의 질문이라고 생각합니다. – Macros

2 쿼리 접근 방식으로 분할하는 방법이 있는지 확실하지 않습니다. 특히 쿼리에서 여러 매개 변수에 대해이 방식을 사용하는 경우에는 복잡한 쿼리를 동기화하는 것이 다소 어려울 수 있습니다. –

스캔 클러스터 된 인덱스에 의해 수 있습니다 채택된다는 것이다 당신은 테이블 파션을 사용합니다. 문제를 해결할 수 있습니다.

출처

2010-05-07 11:27:21 sanket

은 프로 시저 캐시 메모리 버퍼를 청소하십시오 (언제 어디 절없이 즉, 쿼리) 당신은 반복을 피하기 위해 필요한 열이있는보기를 만들 수 있습니다 프로 시저의 성능을 테스트하면 캐시 된 실행 계획과 이전 결과 캐시를 사용할 수 없게됩니다.

출처

2010-05-07 11:42:29 RoadWarrior

테이블에 몇 개의 행이 있습니까? "클러스터 된 인덱스 스캔"= 전체 테이블 스캔이라는 것을 알고 있습니다.

출처

2010-05-08 00:18:26

나는하지 않았다. .. 그러나 지금한다! 이 – Macros

좋은 거래를 기반으로 SP를 최적화하는 지난 2 일을 보냈습니다. 아마 당신은 이미 그것을 알아 냈을 것입니다. 그러나 왜 최적화자가 하위 최적 계획을 선택했는지 설명 했어야합니다. 인덱스를 사용할 수없는 이유는 WHERE 절의 (또는 @ID가 null) 부분입니다. NULL 값은 인덱싱되지 않습니다. –

Sql 서버 쿼리 성능

답변

관련 문제