"Advertencias: la operación causó E / S residual" versus búsquedas clave

He visto esta advertencia en los planes de ejecución de SQL Server 2017:

Advertencias: La operación causó IO residual [sic]. El número real de filas leídas fue (3.321.318), pero el número de filas devueltas fue 40.

Aquí hay un fragmento de SQLSentry PlanExplorer:

Para mejorar el código, agregué un índice no agrupado para que SQL Server pueda acceder a las filas relevantes. Funciona bien, pero normalmente habría demasiadas (grandes) columnas para incluir en el índice. Se parece a esto:

Si solo agrego el índice, sin incluir columnas, se ve así, si fuerzo el uso del índice:

Obviamente, SQL Server cree que la búsqueda de claves es mucho más costosa que la E / S residual. Tengo una configuración de prueba sin muchos datos de prueba (todavía), pero cuando el código entra en producción, necesita trabajar con muchos más datos, por lo que estoy bastante seguro de que se necesita algún tipo de índice no agrupado.

¿Son realmente costosas las búsquedas de claves , cuando se ejecuta en SSD, que tengo que crear índices completos (con muchas columnas de inclusión)?

Plan de ejecución: https://www.brentozar.com/pastetheplan/?id=SJtiRte2X Es parte de un largo procedimiento almacenado. Buscar IX_BatchNo_DeviceNo_CreatedUTC.

El modelo de costo utilizado por el optimizador es exactamente eso: un modelo . En general, produce buenos resultados en una amplia gama de cargas de trabajo, en una amplia gama de diseños de bases de datos, en una amplia gama de hardware.

En general, no debe suponer que las estimaciones de costos individuales se correlacionarán fuertemente con el rendimiento en tiempo de ejecución en una configuración de hardware particular. El punto del costeo es permitir que el optimizador haga una elección informada entre alternativas físicas candidatas para la misma operación lógica.

Cuando realmente entras en los detalles, un profesional experto en bases de datos (con tiempo para ajustar una consulta importante) a menudo puede hacerlo mejor. En ese sentido, puede pensar en la selección del plan del optimizador como un buen punto de partida. En la mayoría de los casos, ese punto de partida también será el punto final, ya que la solución encontrada es lo suficientemente buena .

En mi experiencia (y opinión), el optimizador de consultas de SQL Server cuesta búsquedas más altas de lo que preferiría. Esto es en gran parte una resaca de los días en que la E / S física aleatoria era mucho más costosa en comparación con el acceso secuencial de lo que suele ser el caso hoy.

Aún así, las búsquedas pueden ser costosas incluso en SSD, o en última instancia, incluso cuando se lee exclusivamente de memoria. Atravesar estructuras de b-tree no es gratis. Obviamente, el costo aumenta a medida que haces más de ellos.

Las columnas incluidas son excelentes para cargas de trabajo OLTP con mucha lectura, donde tiene sentido la compensación entre el uso del espacio de índice y el costo de actualización versus el rendimiento de lectura en tiempo de ejecución. También hay una compensación a considerar en torno a la estabilidad del plan . Un índice de cobertura total evita la pregunta de cuándo exactamente el modelo de costo del optimizador podría pasar de una alternativa a otra.

Solo usted puede decidir si las compensaciones valen la pena en su caso. Pruebe ambas alternativas en una muestra de datos representativa y tome una decisión informada.

En un comentario de pregunta que agregó:

¿Me está diciendo que SQL Server no conoce el costo del IO residual?

No, el optimizador considera el costo de la E / S residual. De hecho, en lo que respecta al optimizador, los predicados no SARGable se evalúan en un filtro separado. Este filtro se inserta en la búsqueda o exploración como un residuo durante las reescrituras posteriores a la optimización .