Estoy uniendo una tabla pequeña (1,000 filas) contra una tabla grande (8M filas) en SQL Server 2008. La combinación usa un índice de cobertura no agrupado en la tabla grande, y la unión puede producir tres posibles planes de consulta. Estoy tratando de averiguar qué plan es mejor, pero también quiero generalizar este conocimiento para que la próxima vez pueda saber mejor qué heurística usar al mirar las estadísticas de E / S de SQL.
El plan n. ° 1 es una unión en bucle y emite estadísticas para la tabla grande como esta:
Scan count 2582, logical reads 35686, physical reads 1041, read-ahead reads 23052El plan n. ° 2 es una combinación de combinación y emite estadísticas como esta:
Scan count 1, logical reads 59034, physical reads 49, read-ahead reads 59004Plan # 3 es un hash join y emite estadísticas como esta:
Scan count 3, logical reads 59011, physical reads 5, read-ahead reads 59010El índice de cobertura está ordenado por (ID, Date). La consulta devuelve datos de aproximadamente el 50% de las ID y, para cada ID, devuelve un fragmento contiguo de los últimos 3 meses de datos, que suele ser aproximadamente 1/4 o las filas de cada ID. La consulta devuelve aproximadamente 1/8 del total de filas en el índice. En otras palabras, la consulta es escasa pero consistentemente.
Mi suposición es que el plan n. ° 1 es horrible para esta carga de trabajo, porque mover la cabeza del disco alrededor de 2.500 veces (o incluso 1.041 veces) es mucho más costoso que una exploración de disco secuencial. También supongo que # 3 y # 2 tienen patrones de E / S similares, secuenciales (y, por lo tanto, más eficientes).
Pero, ¿hay algún caso en el que el plan n. ° 1 sea realmente mejor, donde "mejor" signifique menos impacto en el subsistema de E / S y menos impacto en otras consultas que se ejecutan simultáneamente?
¿O realmente depende de muchas variables como el tipo de subsistema de disco que tengo, la fragmentación del índice, etc. Si "depende", hay alguna regla general para abordar el problema?