Anvend betinget filtrering i WHERE-sætningen

Først denne ((J.Id = @Jobid and @Jobid>0) or @Jobid=0) kan erstattes
med denne (@Jobid = 0 or J.Id = @Jobid) .Bemærk, at siden 0 er åbenbart ikke en gyldig værdi for job-id (eller medarbejder eller lead), and del er irrelevant, da ingen post nogensinde vil indeholde et id på 0.

For det andet, brug ikke 0 som en ugyldig værdi, brug null i stedet. det vil ikke påvirke ydeevnen, men det er en bedre programmeringsvane, da 0 kan meget vel være en gyldig værdi i andre situationer.

For det tredje er catch-all-forespørgsler kendt for at blive ramt af ydeevnen, især i lagrede procedurer, da den cachelagrede eksekveringsplan måske ikke er den bedste til den aktuelle udførelse. Så vidt jeg ved, er den bedste måde at håndtere dette på at tilføje et genkompileringstip til forespørgslen, som foreslået i denne artikel og i denne artikel .

Så jeg foreslår, at din forespørgsel ser sådan ud:

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

Vælg ydeevne forbedres normalt med korrekt indeksering af tabellerne. Korrekt indeksering kræver dog viden, som ikke alle udviklere har. Det er et emne, der er værd at læse om. Jeg ville starte her .