Primero, este ((J.Id = @Jobid and @Jobid>0) or @Jobid=0) se puede reemplazar
con este (@Jobid = 0 or J.Id = @Jobid) .Tenga en cuenta que desde 0 obviamente no es un valor válido para la identificación del trabajo (o empleado o cliente potencial), el and parte es irrelevante ya que ningún registro contendrá una identificación de 0.
Segundo, no uses 0 como un valor no válido, use null en cambio. no afectará el rendimiento, pero es un mejor hábito de programación, ya que 0 podría muy bien ser un valor válido en otras situaciones.
En tercer lugar, se sabe que las consultas generales sufren un impacto en el rendimiento, especialmente en los procedimientos almacenados, ya que el plan de ejecución en caché podría no ser el mejor para la ejecución actual. Que yo sepa, la mejor manera de manejar esto es agregar una sugerencia de recompilación a la consulta, como se sugiere en este artículo y en ese artículo .
Entonces, sugiero que su consulta se vea así:
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
El rendimiento seleccionado generalmente se mejora con la indexación correcta de las tablas. Sin embargo, indexar correctamente requiere conocimientos que no todos los desarrolladores tienen. Es un tema sobre el que vale la pena leer. empezar aquí .
