También podría simplemente colocar el primer SELECT en una sub consulta. Dado que la mayoría de los optimizadores lo doblarán en una constante de todos modos, no debería haber un golpe de rendimiento en esto.
Por cierto, dado que está utilizando un predicado como esto:
CONVERT(...) = CONVERT(...)
ese predicado expresión no puede ser optimizado correctamente o el uso de índices en la referencia de columnas por la función CONVERT().
Aquí es una manera de hacer la consulta original algo mejor:
DECLARE @ooDate datetime
SELECT @ooDate = OO.Date FROM OLAP.OutageHours AS OO where OO.OutageID = 1
SELECT
COUNT(FF.HALID)
FROM
Outages.FaultsInOutages AS OFIO
INNER JOIN Faults.Faults as FF ON
FF.HALID = OFIO.HALID
WHERE
FF.FaultDate >= @ooDate AND
FF.FaultDate < DATEADD(day, 1, @ooDate) AND
OFIO.OutageID = 1
Esta versión podría aprovechar en el índice que involucró FaultDate, y logra el mismo objetivo.
Aquí está, reescrito para usar una subconsulta para evitar la declaración de la variable y SELECT subsiguiente.
SELECT
COUNT(FF.HALID)
FROM
Outages.FaultsInOutages AS OFIO
INNER JOIN Faults.Faults as FF ON
FF.HALID = OFIO.HALID
WHERE
CONVERT(varchar(10), FF.FaultDate, 126) = (SELECT CONVERT(varchar(10), OO.Date, 126) FROM OLAP.OutageHours AS OO where OO.OutageID = 1) AND
OFIO.OutageID = 1
Tenga en cuenta que este enfoque tiene el mismo problema el uso de índices como el original, debido a la utilización de CONVERT() en FF.FaultDate. Esto podría remediarse agregando la subconsulta dos veces, pero en este caso estaría mejor atendido con el enfoque variable. Esta última versión es solo para demostración.
Atentamente.
por primera ejemplo que proporcionó, debe envolver el "conteo de selección (*) del usuario" entre paréntesis o sql 2008 se mostrará con una línea roja ondulada. ¡Gracias por proporcionar dos ejemplos de sintaxis! – TWood