쿼리 성능을 향상시키는 방법

테이블에 많은 레코드가 있습니다. 다음 쿼리를 실행하면 많은 시간이 걸립니다. 성능을 어떻게 향상시킬 수 있습니까?쿼리 성능을 향상시키는 방법

SET ROWCOUNT 10 
SELECT StxnID 
     ,Sprovider.description as SProvider 
     ,txnID 
     ,Request 
     ,Raw 
     ,Status 
     ,txnBal 
     ,Stxn.CreatedBy 
     ,Stxn.CreatedOn 
     ,Stxn.ModifiedBy 
     ,Stxn.ModifiedOn 
     ,Stxn.isDeleted 
    FROM Stxn,Sprovider 
    WHERE Stxn.SproviderID = SProvider.Sproviderid 
    AND Stxn.SProviderid = ISNULL(@pSProviderID,Stxn.SProviderid) 
    AND Stxn.status = ISNULL(@pStatus,Stxn.status) 
    AND Stxn.CreatedOn BETWEEN ISNULL(@pStartDate,getdate()-1) and ISNULL(@pEndDate,getdate()) 
    AND Stxn.CreatedBy = ISNULL(@pSellerId,Stxn.CreatedBy) 
    ORDER BY StxnID DESC

stxn 테이블에는 100,000 개가 넘는 레코드가 있습니다.

쿼리는 asp.net C#의 보고서 뷰어에서 실행됩니다.

출처

2011-07-29 chetan singhal

테이블, 색인 등이 어찌 알지 못해서 힘들어 할 것입니다. 실행 계획을 우리에게 보여 주시길 바랍니다. –

어떤 버전의 SQL Server입니까? –

저장 절차가 있습니다. 나는 저장 프로 시저를 검색하기 위해 데이터 세트를 사용합니다. –

Stxn.SproviderID, Stxn.status, Stxn.CreatedOn, Stxn.CreatedBy, Stxn.StxnID 및 SProvider.Sproviderid에 모두 인덱스가 정의되어 있는지 확인하십시오.

(NB - 모든 필요하지 않을 수도 있지만 해치지 않을 수 있습니다.) 내가 쿼리 자체에서 수행 할 수있는 정도가 표시되지

출처

2011-07-29 16:41:30 Hogan

,하지만 난에 수행되는 것을 볼 수 있습니다 스키마

이
상태에 인덱스를 생성 SProvider.Sproviderid
Stxn.SproviderID

,691을 StxnID

출처

2011-07-29 16:41:48

실행 계획을 사용하고 누락 된 색인을 찾아보십시오. 또한 실행하는 데 얼마나 걸립니까? 너 왜 느린거야?

아마도 너무 많은 행을 반환 할 수는 없겠지만, 이는 단지 추측 일뿐입니다. 사실 우리는 당신의 테이블과 인덱스와 실행 계획을 볼 필요가 있습니다.

확인 sql-tuning-tutorial

출처

2011-07-29 16:41:50

이것은 내 이동 - 투 I는 선택 사양 일 수있는 몇 가지 검색 조건을 가진 검색 쿼리를 할 노력하고있어 기사.

http://www.sommarskog.se/dyn-search-2008.html

쿼리의 가장 큰 문제는 column=ISNULL(@column, column) 구문입니다. MSSQL은 인덱스를 사용하지 않습니다. 변경하려면 (column = @column AND @column IS NOT NULL)

출처

2011-07-29 16:43:27

SET ROWCOUNT 대신 SELECT TOP()을 사용하십시오. 옵티 마이저의 경우 훨씬 더 좋은 방법입니다. 또 다른 제안은 기존의 스타일 테이블, 테이블 조인 구문을 사용하는 데카르트 제품으로 잠재적으로 끝나는 대신 적절한 내부 조인을 사용하는 것입니다 (이 경우는 아니지만 이전 구문의 경우 훨씬 쉽습니다).

... 
FROM Stxn INNER JOIN Sprovider 
    ON Stxn.SproviderID = SProvider.Sproviderid 
...

을 그리고 당신이 100K 행을 생각하면 많은 경우, 또는이 볼륨이 속도 저하에 대한 이유는, 당신은 착각 위치 :이어야한다. 대부분의 경우, 인덱싱 전략이 잘못되어있을 가능성이 있으며, 일부 매개 변수 스니핑 (sniffing), 아마도 암시 적 변환 (implicit conversion) 등이있을 수 있습니다. 데이터 유형, 인덱스 및 계획을 이해하지 않고도 쉽게 알 수 없습니다.

출처

2011-07-29 16:44:01

쿼리 성능에 영향을 줄 수있는 많은 작업이 있습니다. 100k 레코드가 실제로 그렇게 많은 것은 아닙니다.(특별한 순서없이) 고려해야 할

항목

하드웨어 :

는 SQL Server 메모리가 구속되어 있습니까? 다른 말로하면, 그 일을하기에 충분한 RAM이 있습니까? 메모리를 디스크로 스와핑하는 경우에는 업그레이드가 필요하다는 것을 나타내는 확실한 신호입니다.

기계 디스크가 구속되어 있습니까? 즉, 실행해야하는 쿼리를 따라갈 수있을 정도로 드라이브가 빠릅니까? 메모리가 제한되어 있으면 디스크 속도가 더 큰 요인이됩니다.

기계 프로세서가 구속되어 있습니까? 예를 들어, 쿼리를 실행할 때 프로세서가 오랜 기간 동안 급증합니까? 당신의 where 절에 당신이 열에 인덱스가 수행을

을 사용 : 또는 멀리 당신의 자원을 복용하는 다른 쿼리를 실행 많이

데이터베이스 구조를 ... 이미입니까? 테이블에 인덱스가없는 경우 일치하는 레코드를 결정하기 위해 두 테이블을 모두 검색해야합니다.

ISNULL 함수 호출을 제거하십시오. 직접 쿼리 인 경우 호출 코드에서 매개 변수의 유효성을 검사하고 실행 전에 기본값을 설정하십시오. 저장 프로 시저에 있으면 s'proc의 맨 위에서 검사를 수행하십시오. 당신이 매개 변수 스니핑 않습니다 RECOMPILE이를 실행하지 않는 한, 이러한 기능은 .. 각 행에 대해 평가되어야 할 것이다

네트워크 :

당신과 서버 사이의 느린 네트워크인가? 가져온 데이터의 양에 따라 유선을 통해 GB의 데이터를 가져올 수 있습니다. "원시"열에 저장되는 항목이 확실하지 않습니다. 여기서 질문해야 할 첫 번째 질문은 "얼마나 많은 데이터가 클라이언트로 돌아갈 것입니까?"입니다. 예를 들어 각 레코드의 크기가 1MB 이상인 경우 디스크 및 네트워크 제약 조건이 적용될 수 있습니다. 일반

:

나는 귀하의 질문에 무엇을 의미하는지 "느린"모르겠어요. 쿼리가 처리하는 데 약 1 초가 걸리거나 5 분이 걸린다는 의미입니까? 모든 것은 여기서 상대적입니다.

기본적으로 많은 질문없이 어려운 답변을 제공하는 것은 불가능합니다. 당신이 질의를 분석하고, 클라이언트에게 무엇이 얼마나 많은 양으로 돌아가는지를 이해하고 다양한 부분들 사이의 상호 작용을 관찰하면 이러한 모든 것들이 사라질 것입니다.

마지막으로 클라이언트로 되돌아 오는 데이터 양에 따라 하드웨어 변경이 부족하여 성능을 향상시킬 방법이 없을 수 있습니다.

출처

2011-07-29 16:48:50 NotMe

주의 사항 : ROWCOUNT 또는 TOP를 ORDER BY 절과 함께 사용하면 전체 결과 집합이 먼저 만들어지고 정렬 된 다음 상위 10 개 결과가 반환됩니다.

Order By 절없이 어떻게 실행됩니까?

출처

2011-07-29 17:15:49

쿼리 성능을 향상시키는 방법

답변

관련 문제