Performance when adding a parameter to where clause - sql

Question

I'm trying to understand this behaviour. My below statement takes nearly half an hour to complete. However when I replace the parameter #IsGazEnabled (in the case statement of the where clause at the bottom) with a value of 1, then it takes just a second.
Looking at the estimated execution plan, when using the parameter and when it takes 30 minutes, most of the cost (92%) lies with a Nested Loop (Left Anti Semi Join). there also seems to be some Parallelism going on. I'm only just learning about Execution plans and I'm left a bit confused. Very different to the plan produced when not using the parameter.
So how does having a parameter compared to not having one make such a difference to the execution plan and performance?
declare #IsGazEnabled tinyint;
set #IsGazEnabled = 1;
select 'CT Ref: ' + accountreference + ' - Not synced due to missing property ref ' + t.PropertyReference
from CTaxAccountTemp t
where not exists (
select *
from ccaddress a
left join w2addresscrossref x on x.UPRN = a.UPRN
and x.appcode in (
select w2source
from GazSourceConfig
where GazSource in (
select GazSource
from GazSourceConfig
where W2Source = 'CTAX'
)
union all select 'URB'
)
where t.PropertyReference = case #IsGazEnabled when 1 then x.PropertyReference else a.PropertyReference end
);

Answer 1

This can occur because SQL Server (the query optimizer) uses the value of the provided parameter when creating the initial execution plan. If the values in some of your tables are not evenly distributed, the created plan may work really well for certain values of the parameter, but really poorly for others. This is generally referred to a parameter sniffing. You can get around this using query hints (OPTIMIZE FOR X) or recompiling the stored procedure before each run (WITH RECOMPILE). You should read up on these options thoroughly before implementing as they both have side effects.
See a couple articles on Brent Ozar's site for more details, here and here.

Answer 2

I think you should rethink this query. Try and avoid the NOT EXISTS() for starters - as thats generally quite inefficient (I usually prefer a LEFT JOIN in these instances - and a corresponding WHERE x IS NULL - the x being something in the right hand side)
The main cause of woe for you though is likely to be the CASE based WHERE - as that is now causing the inner query to be evaluated for EVERY ROW!. I think you'd be better left joining both sets of disqualifying criteria, but include the parameter in the join conditions - and then check that there is nothing on the right hand side of either of the 2 left joined criteria
Heres how I think it could be rewritten:
declare #IsGazEnabled tinyint;
set #IsGazEnabled = 1;
select 'CT Ref: ' + accountreference + ' - Not synced due to missing property ref ' + t.PropertyReference
from CTaxAccountTemp t
left join ccaddress a2 ON t.PropertyReference = a2.PropertyReference and #IsGazEnabled = 0
left join
(
ccaddress a
join w2addresscrossref x on x.UPRN = a.UPRN
and x.appcode in ( -- could make this a join for efficiency....
select w2source
from GazSourceConfig
where GazSource in (
select GazSource
from GazSourceConfig
where W2Source = 'CTAX'
)
union all select 'URB'
)
) ON t.PropertyReference = x.PropertyReference AND and #IsGazEnabled = 1
WHERE
a2.PropertyReference IS NULL
AND x.PropertyReference IS NULL
;