Najpierw ten ((J.Id = @Jobid and @Jobid>0) or @Jobid=0) można zastąpić
tym (@Jobid = 0 or J.Id = @Jobid) .Zauważ, że od 0 oczywiście nie jest prawidłową wartością identyfikatora stanowiska (lub pracownika lub potencjalnego klienta), and część jest nieistotna, ponieważ żaden rekord nigdy nie będzie zawierał identyfikatora 0.
Po drugie, nie używaj 0 jako nieprawidłową wartość użyj null zamiast. nie wpłynie to na wydajność, ale jest to lepszy nawyk programowania, ponieważ 0 może równie dobrze być prawidłową wartością w innych sytuacjach.
Po trzecie, wiadomo, że zapytania typu catch-all mają negatywny wpływ na wydajność, zwłaszcza w procedurach składowanych, ponieważ buforowany plan wykonania może nie być najlepszy dla bieżącego wykonania. Według mojej najlepszej wiedzy najlepszym sposobem na rozwiązanie tego problemu jest dodanie do zapytania wskazówki dotyczącej ponownej kompilacji, zgodnie z sugestią w ten artykuł oraz w w tym artykule .
Sugeruję więc, aby Twoje zapytanie wyglądało tak:
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
Wybrane wydajności są zwykle poprawiane przez prawidłowe indeksowanie tabel. Jednak prawidłowe indeksowanie wymaga wiedzy, której nie posiadają wszyscy programiści. To temat, o którym warto poczytać. zacząłbym tutaj .
