Innanzitutto, questo ((J.Id = @Jobid and @Jobid>0) or @Jobid=0) può essere sostituito
con questo (@Jobid = 0 or J.Id = @Jobid) .Nota che da 0 ovviamente non è un valore valido per job id (o impiegato o lead), and parte è irrilevante poiché nessun record conterrà mai un ID pari a 0.
Secondo, non usare 0 come valore non valido, usa null invece. non influirà sulle prestazioni, ma è una migliore abitudine di programmazione, poiché 0 potrebbe benissimo essere un valore valido in altre situazioni.
In terzo luogo, è noto che le query catch-all subiscono un calo delle prestazioni, soprattutto nelle procedure archiviate, poiché il piano di esecuzione memorizzato nella cache potrebbe non essere il migliore per l'esecuzione corrente. Per quanto ne so, il modo migliore per gestire questo problema è aggiungere un suggerimento di ricompilazione alla query, come suggerito in questo articolo e in questo articolo .
Quindi, suggerisco che la tua query assomigli a questa:
CREATE PROCEDURE <procedure name>
(
@Jobid INT=NULL,
@leadid INT=NULL,
@employeeid INT=NULL
)
AS
SELECT e.id,
l.id,
j.id,
e.NAME,
l.NAME,
j.NAME
FROM employee e
INNER JOIN leads l
ON e.leadid = l.id
INNER JOIN Jobs j
ON j.id = e.Jobid
WHERE (@Jobid IS NULL OR J.Id = @Jobid)
AND (@leadid IS NULL OR l.Id = @leadid)
AND (@employeeid IS NULL OR e.Id = @employeeid)
OPTION(RECOMPILE)
GO
le prestazioni selezionate sono generalmente migliorate con una corretta indicizzazione delle tabelle. Tuttavia, l'indicizzazione corretta richiede conoscenze che non tutti gli sviluppatori hanno. È un argomento che vale la pena leggere. Vorrei iniziare qui .
