lecturas lógicas vs recuento de escaneo

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 23052

El 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 59004

Plan # 3 es un hash join y emite estadísticas como esta:

Scan count 3, logical reads 59011, physical reads 5, read-ahead reads 59010

El í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?

Aquí está el trato asesino: en enero costaba $ 12k comprar 864 * GB * de RAM . Puede obtener una gran cantidad de dinero simplemente aumentando la RAM de su servidor hasta el punto de que nunca alcanzará una lectura física (después del calentamiento, por supuesto).

Aparte de eso, es realmente difícil dar una opinión en blanco o negro sobre cualquiera de esos puntos de datos que presenta. Claro que el plan # 1 tuvo la mayoría de las lecturas físicas, pero ¿está seguro de que todas las pruebas se realizaron en un caché calentado de manera similar? ¿Podría ser que el # 1 calienta el caché para el # 2, cuál es su metodología de prueba para garantizar que todos los casos se consideren en terreno nivelado? Aun así, si paga $ 500 y duplica la RAM, ¿importaría más? # 1 tiene las lecturas menos lógicas ...

Pero entonces el # 2 probablemente se beneficie de una DOP alta (ese escaneo puede ser paralelo). ¿Es el tiempo del reloj de pared del n. ° 2 mejor que el n. ° 1 después de agregar suficiente RAM?

¿Cuántos de estos planes se ejecutan en paralelo? ¿Hay decenas de consultas que solicitan simultáneamente una concesión de memoria significativa para el hash del n. ° 3 y, por lo tanto, crean contención para RESOURCE_SEMAPHORE? ¿El # 2 está haciendo una especie y también solicita una concesión de memoria? ¿Funcionará mejor # 1 ya que no requiere subvención (al menos de la información publicada ...)?

Es realmente muy relativo y la pregunta que hace es más como encontrar una solución para un sistema complejo de ecuaciones ... simplemente podría haber más de una solución.

Una cosa es segura: las filas de 8 millones deberían caber en la RAM con suficiente espacio libre. Esas lecturas físicas están pidiendo algunos bancos de memoria.

Para esta consulta aparentemente muy simple, el optimizador producirá consistentemente el mejor plan de acuerdo con su modelo de costos. El modelo de costos es bastante preciso. Entonces, mi recomendación sería dejar la elección a SQL Server.

Segunda recomendación: Mida la duración de la consulta para las tres variantes con un caché activo. Entonces decide. (No decida basándose en lecturas y escaneos y demás. Lo que le importa es la duración).

En general, elegir el mejor tipo de unión (o índices) requiere comprender cómo funcionan los algoritmos de unión. Esa es demasiada información para publicar aquí.

Ignorar el recuento de escaneo, no es importante. Concéntrese en cómo reducir las lecturas lógicas. Basado en http://www.practicalsqldba.com/2013/07/sql-server-performance-tuning.html .