ストアドプロシージャで選択肢が多すぎますか？

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

実際にやりとりしてパフォーマンスの違いを見なければならないことがいくつかあります。まず第一に、前の答えが示唆しているように、可能な限り集団のような数（*）を省略すべきです。テーブルが非常に大きい場合、これらの関数のコストは指数関数的に増加します。これらのカウントを適切なインデックス制約を持つ別のテーブルに格納することも考えられます。

また、select文を複数の文に分割することをお勧めします。なぜなら、非常に多くのNULLチェック、または、および条件を組み合わせて使用​​すると、インデックスがバイパスされ、クエリのコストが大幅に増加する可能性があります。 UNIONを使用すると、そのような条件を使用するよりもはるかに優れたパフォーマンスが得られることがあります。

実は、あなたはこれらすべてを試してみて

はそれが役に立てば幸いニーズに合ったものを見る必要があります。

Answer 3

@table変数の宣言は表示されませんが、その中のIDが一意であると仮定して、この情報をオプティマイザに伝えることを検討してください。IOWは主キー制約を追加します。

また、クエリの末尾にoption(recompile)を追加します。