Appliquer le filtrage conditionnel dans la clause WHERE

Tout d'abord, ce ((J.Id = @Jobid and @Jobid>0) or @Jobid=0) peut être remplacé
par ce (@Jobid = 0 or J.Id = @Jobid) .Notez que depuis 0 n'est évidemment pas une valeur valide pour l'ID de poste (ou l'employé ou le prospect), le and partie n'est pas pertinente car aucun enregistrement ne contiendra jamais un identifiant de 0.

Deuxièmement, n'utilisez pas 0 comme valeur invalide, utilisez null Au lieu. cela n'affectera pas les performances, mais c'est une meilleure habitude de programmation, puisque 0 pourrait très bien être une valeur valide dans d'autres situations.

Troisièmement, les requêtes fourre-tout sont connues pour souffrir de problèmes de performances, en particulier dans les procédures stockées, car le plan d'exécution mis en cache peut ne pas être le meilleur pour l'exécution en cours. À ma connaissance, la meilleure façon de gérer cela est d'ajouter un indice de recompilation à la requête, comme suggéré dans cet article et dans cet article .

Donc, je suggère que votre requête ressemble à ceci :

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

Les performances de select sont généralement améliorées avec une indexation correcte des tables. Cependant, l'indexation nécessite correctement des connaissances que tous les développeurs n'ont pas. C'est un sujet qui vaut la peine d'être lu. Je commencerais ici .