1

I have this query(of course with couple joins across tables and some views which I will call x for simplicity).

  1. Case 1 : select * from x -> returns in 10 sec, still acceptable, fairly heavy on joins and lot of data
  2. Case 2 : select * from x where userid = 1 -> returns in 0-1 sec, good enough

  3. Case 3 : using SP : if @userid = -1 select * from x else select from x where userid = @userid -> now calling sp with paramenter userid 1 should return on 0-1 sec as it should be comparable to case 2 but in fact it returns in 10 sec.

    Now, parameter masking OR WITH RECOMPILE on sp OR OPTION (recompile) on query with where clause doesn't help, What makes the SP run faster with userid = something is putting OPTION(recompile) on the first part of the SP ie on the query without where clause. :

  4. Case 4 : using SP : if @userid = -1 select * from x option (recompile) else select * from x where userid = @userid

Any explanation?

I can guess earlier it was using optimization based of query without where clause even for the query with where clause, but why is that?

4

1 に答える 1

1

ストアド プロシージャは実行計画をキャッシュするため、SP が呼び出されるたびにクエリを再コンパイルするオーバーヘッドがありません。これは、トランザクションにストアド プロシージャを使用する場合に特に重要です。クエリが数秒間実行されている場合は、それほど重要ではありません。

クエリがパラメーターを受け取る場合、ストアド プロシージャは最適化する値を決定する必要があります。SQL Server は 2 つのクエリが同一であると認識し、同じキャッシュ プランを使用していると思います。最初のクエリに基づいて計画を最適化しています。これは憶測ですが、あなたが見ているものを説明するでしょう.

これは、次のバージョンのクエリで簡単に修正できます。

select *
from x
where @userid = -1 or userid = @userid
option (recompile)
于 2012-09-19T18:18:46.520 に答える