SQL IN () versus OR

Estaba trabajando con una consulta que escribí hoy, tenía que cambiar el código de la WHEREcláusula para usar un filtro IN (lista de cosas) en lugar de usar algo como

item_desc = 'item 1'
OR item_desc = 'item 2'
OR item_desc = 'item 3'
OR item_desc = 'item 4'

Lo anterior se ejecutó durante 15 minutos y no devolvió nada, sin embargo, lo siguiente me dio mi conjunto de resultados en 1,5 minutos

item_desc IN (
'item 1'
,'item 2'
,'item 3'
,'item 4'
)

Hice esto en SQL y me pregunto por qué el IN (lista de elementos) se desempeñó mucho más rápido que la instrucción OR.

- EDITAR - SQL Server 2008, me disculpo por no poner esta información en primer lugar.

Aquí está la consulta en su totalidad utilizando las ORdeclaraciones:

DECLARE @SD DATETIME
DECLARE @ED DATETIME
SET @SD = '2013-06-01';
SET @ED = '2013-06-15';

-- COLUMN SELECTION
SELECT PV.PtNo_Num AS 'VISIT ID'
, PV.Med_Rec_No AS 'MRN'
, PV.vst_start_dtime AS 'ADMIT'
, PV.vst_end_dtime AS 'DISC'
, PV.Days_Stay AS 'LOS'
, PV.pt_type AS 'PT TYPE'
, PV.hosp_svc AS 'HOSP SVC'
, SO.ord_no AS 'ORDER NUMBER'
--, SO.ent_dtime AS 'ORDER ENTRY TIME'
--, DATEDIFF(HOUR,PV.vst_start_dtime,SO.ent_dtime) AS 'ADM TO ENTRY HOURS'
, SO.svc_desc AS 'ORDER DESCRIPTION'
, OSM.ord_sts AS 'ORDER STATUS'
, SOS.prcs_dtime AS 'ORDER STATUS TIME'
, DATEDIFF(DAY,PV.vst_start_dtime,SOS.prcs_dtime) AS 'ADM TO ORD STS IN DAYS'

-- DB(S) USED
FROM smsdss.BMH_PLM_PtAcct_V PV
JOIN smsmir.sr_ord SO
ON PV.PtNo_Num = SO.episode_no
JOIN smsmir.sr_ord_sts_hist SOS
ON SO.ord_no = SOS.ord_no
JOIN smsmir.ord_sts_modf_mstr OSM
ON SOS.hist_sts = OSM.ord_sts_modf_cd

-- FILTER(S)
WHERE PV.Adm_Date BETWEEN @SD AND @ED
AND SO.svc_cd = 'PCO_REMFOLEY'
OR SO.svc_cd = 'PCO_INSRTFOLEY'
OR SO.svc_cd = 'PCO_INSTFOLEY'
OR SO.svc_cd = 'PCO_URIMETER'

AND SO.ord_no NOT IN (
    SELECT SO.ord_no
    FRROM smsdss.BMH_PLM_PtAcct_V PV
    JOIN smsmir.sr_ord SO
    ON PV.PtNo_Num = SO.episode_no
    JOIN smsmir.sr_ord_sts_hist SOS
    ON SO.ord_no = SOS.ord_no
    JOIN smsmir.ord_sts_modf_mstr OSM
    ON SOS.hist_sts = OSM.ord_sts_modf_cd
    WHERE OSM.ord_sts = 'DISCONTINUE'
    AND SO.svc_cd = 'PCO_REMFOLEY'
    OR SO.svc_cd = 'PCO_INSRTFOLEY'
    OR SO.svc_cd = 'PCO_INSTFOLEY'
    OR SO.svc_cd = 'PCO_URIMETER'
)
ORDER BY PV.PtNo_Num, SO.ord_no, SOS.prcs_dtime

Gracias,

La respuesta de Oleski es incorrecta. Para SQL Server 2008, una INlista se refactoriza a una serie de ORdeclaraciones. Puede ser diferente en decir MySQL.

Estoy bastante seguro de que si generara planes de ejecución reales para ambas consultas, serían idénticas.

Con toda probabilidad, la segunda consulta se ejecutó más rápido porque la ejecutó en segundo lugar , y la primera consulta ya había extraído todas las páginas de datos de la base de datos y pagado el costo de IO. La segunda consulta pudo leer todos los datos de la memoria y ejecutarse mucho más rápido.

Actualizar

La fuente real de la variación es probable que las consultas no sean equivalentes . Tienes dos ORlistas diferentes a continuación:

WHERE PV.Adm_Date BETWEEN @SD AND @ED
AND SO.svc_cd = 'PCO_REMFOLEY'
OR SO.svc_cd = 'PCO_INSRTFOLEY'
OR SO.svc_cd = 'PCO_INSTFOLEY'
OR SO.svc_cd = 'PCO_URIMETER'

y después

 WHERE OSM.ord_sts = 'DISCONTINUE'
    AND SO.svc_cd = 'PCO_REMFOLEY'
    OR SO.svc_cd = 'PCO_INSRTFOLEY'
    OR SO.svc_cd = 'PCO_INSTFOLEY'
    OR SO.svc_cd = 'PCO_URIMETER'

En ambas WHEREcláusulas, la precedencia del operador (donde AND se maneja antes que OR) significa que la lógica real ejecutada por el motor es:

WHERE (ConditionA AND ConditionB)
OR ConditionC
OR ConditionD
OR ConditionE

Si reemplaza las ORlistas con una INexpresión, la lógica será:

WHERE ConditionA
AND (ConditionB OR ConditionC OR ConditionD OR ConditionE)

Lo cual es radicalmente diferente.

La mejor manera de saberlo es mirar el plan de consulta real usando algo como EXPLAIN. Esto debería decirle exactamente lo que está haciendo el DBMS, y luego puede tener una mejor idea de por qué es más eficiente.

Dicho esto, los sistemas DBMS son realmente buenos para realizar operaciones entre dos tablas (como uniones). Gran parte del tiempo del optimizador se gasta en estas partes de las consultas porque generalmente son más caras.

Por ejemplo, el DBMS podría ordenar esa INlista y, utilizando un índice item_desc, filtrar los resultados muy rápidamente. No puede hacer esa optimización cuando enumera un montón de selecciones como en el primer ejemplo.

Cuando lo usa IN, está haciendo una tabla improvisada y filtrando usando estas técnicas de combinación de tablas más eficientes.

EDITAR : publiqué esta respuesta antes de que OP mencionara el DBMS específico. Esto resulta que NO es cómo SQL Server trata esta consulta, pero podría ser válido para otros sistemas DBMS. Consulte la respuesta de JNK para obtener una respuesta más específica y precisa.