sql >> Base de Datos >  >> RDS >> Sqlserver

¿Por qué es un escaneo de índice y no una búsqueda de índice?

Está usando un Index Scan principalmente porque también está usando un Merge Join. El operador Merge Join requiere dos flujos de entrada que estén clasificados en un orden que sea compatible con las condiciones de Join.

Y está utilizando el operador Merge Join para realizar su INNER JOIN porque cree que será más rápido que el operador Nested Loop Join más típico. Y probablemente tenga razón (generalmente lo es), al usar los dos índices que ha elegido, tiene flujos de entrada que están preordenados de acuerdo con su condición de unión (LocationID). Cuando los flujos de entrada se ordenan previamente de esta manera, las uniones de combinación son casi siempre más rápidas que las otras dos (uniones de bucle y hash).

La desventaja es lo que ha notado:parece estar escaneando todo el índice, entonces, ¿cómo puede ser más rápido si está leyendo tantos registros que tal vez nunca se usen? La respuesta es que los escaneos (debido a su naturaleza secuencial) pueden leer entre 10 y 100 veces más registros por segundo que las búsquedas.

Now Seeks generalmente gana porque son selectivos:solo obtienen las filas que solicita, mientras que los escaneos no son selectivos:deben devolver cada fila en el rango. Pero debido a que los escaneos tienen un mucho mayor velocidad de lectura, con frecuencia pueden superar las búsquedas siempre que la proporción de filas descartadas a filas coincidentes sea menor que la proporción de escanear filas/seg VS. Buscar filas/seg.

¿Preguntas?

Bien, me han pedido que explique más la última oración:

Una "fila descartada" es aquella que lee el escaneo (porque tiene que leer todo en el índice), pero que será rechazada por el operador Merge Join, porque no tiene una coincidencia en el otro lado, posiblemente porque el La condición de la cláusula WHERE ya la ha excluido.

Las "filas coincidentes" son las que leyó y que en realidad coinciden con algo en Merge Join. Estas son las mismas filas que habría leído un Seek si el Scan fuera reemplazado por un Seek.

Puede averiguar cuáles hay mirando las estadísticas en el Plan de consulta. ¿Ves esa enorme flecha gorda a la izquierda del Index Scan? Eso representa cuántas filas cree el optimizador que leerá con el Escaneo. El cuadro de estadísticas del análisis de índice que publicó muestra que las filas reales devueltas son aproximadamente 5,4 millones (5 394 402). Esto es igual a:

TotalScanRows = (MatchingRows + DiscardedRows)

(En mis términos, de todos modos). Para obtener las Filas coincidentes, mire las "Filas reales" informadas por el operador Merge Join (es posible que deba eliminar las 100 PRINCIPALES para obtener esto con precisión). Una vez que sepa esto, puede obtener las filas descartadas:

DiscardedRows = (TotalScanRows - MatchingRows)

Y ahora puedes calcular la proporción.