Först, denna ((J.Id = @Jobid and @Jobid>0) or @Jobid=0)
kan ersättas
med denna (@Jobid = 0 or J.Id = @Jobid)
.Observera att sedan 0
är uppenbarligen inte ett giltigt värde för jobb-id (eller anställd, eller lead), and
del är irrelevant eftersom ingen post någonsin kommer att innehålla ett id på 0.
För det andra, använd inte 0
som ett ogiltigt värde, använd null
istället. det kommer inte att påverka prestandan, men det är en bättre programmeringsvana, eftersom 0
kan mycket väl vara ett giltigt värde i andra situationer.
För det tredje är catch-all-frågor kända för att drabbas av prestanda, särskilt i lagrade procedurer, eftersom den cachade exekveringsplanen kanske inte är den bästa för den aktuella exekveringen. Så vitt jag vet är det bästa sättet att hantera detta att lägga till en omkompileringstips till frågan, som föreslås i denna artikel och i den artikeln .
Så jag föreslår att din fråga ser ut så här:
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älj prestanda förbättras vanligtvis med korrekt indexering av tabellerna. Men korrekt indexering kräver kunskap som inte alla utvecklare har. Det är ett ämne väl värt att läsa om. Jag skulle börja här .