너무 많은 선택 사항을 사용하는 저장 프로 시저?

Question

최근에 클라이언트의 저장 프로 시저에서 성능 튜닝을 시작했는데이 코드 조각에 부딪혀 더 효율적으로 작동 할 수있는 방법을 찾지 못했습니다.

declare @StationListCount int; 
select @StationListCount = count(*) from @StationList; 
declare @FleetsCnt int; 
select @FleetsCnt=COUNT(*) from @FleetIds; 
declare @StationCnt int; 
select @StationCnt=COUNT(*) from @StationIds; 
declare @VehiclesCnt int; 
select @VehiclesCnt=COUNT(*) from @VehicleIds; 

declare @TrIds table(VehicleId bigint,TrId bigint,InRange bit); 

insert into @TrIds(VehicleId,TrId,InRange) 
select t.VehicleID,t.FuelTransactionId,1 
from dbo.FuelTransaction t 
join dbo.Fleet f on f.FleetID = t.FleetID and f.CompanyID=@ActorCompanyID 
where t.TransactionTime>=@From and (@To is null or t.TransactionTime<@To) 
and (@StationListCount=0 or exists (select id fRom @StationList where t.FuelStationID = ID)) 
and (@FleetsCnt=0 or exists (select ID from @FleetIds where ID = t.FleetID)) 
and (@StationCnt=0 or exists (select ID from @StationIds where ID = t.FuelStationID)) 
and (@VehiclesCnt=0 or exists (select ID from @VehicleIds where ID = t.VehicleID)) 
and t.VehicleID is not null 

insert 명령은 전체 절차를 느리게하고 리소스의 99 %를 사용합니다.

I am not sure but i think these nested loops are referring to the queries inside the where clause

나는 매우 내가 이것에 얻을 수있는 도움을 주셔서 감사합니다.

감사합니다.

Answer 1

삽입물은 차량 ID에 1 개의 테이블 만 사용하므로 다른 테이블에 가입 할 필요가 없습니다.

Answer 2

실제로 성능상의 차이점을 살펴보아야 할 몇 가지 사항이 있습니다. 우선, 앞의 대답에서 알 수 있듯이 카운트 (*)를 생략해야합니다 (가능한 한 많이 aggragate하는 것). 테이블이 너무 크면이 함수의 비용이 기하 급수적으로 증가합니다. 이러한 수를 적절한 인덱스 제약 조건을 가진 별도의 테이블에 저장한다고 생각할 수도 있습니다.

많은 수의 NULL 검사, 또는 및 조건을 조합하여 사용하므로 select 문을 여러 문으로 나눌 것을 권장합니다. 쿼리 비용이 많이 들기 위해 인덱스가 무시 될 수 있습니다. 때때로 UNION을 사용하면 이러한 조건을 사용하는 것보다 훨씬 나은 성능을 제공 할 수 있습니다.

사실,이 모든 시도하고

그것이 도움이되기를 바랍니다 귀하의 요구에 맞는 것을 볼 수 있습니다.

Answer 3

@table 변수의 선언이 보이지 않지만 (이 ID가 고유하다고 가정하면)이 정보를 최적화 프로그램에 전달하는 것을 고려하십시오. IOW는 기본 키 제약 조건을 추가합니다.

또한 option(recompile)을 쿼리 끝에 추가하십시오.