¿Los optimizadores de consultas de bases de datos conocen las diferencias de rendimiento de almacenamiento?

Según tengo entendido, el optimizador de consultas en SQL Server (o cualquier otro RDBMS, realmente) no es consciente del rendimiento del almacenamiento debajo de la base de datos, y tomará decisiones como si todo el almacenamiento tuviera el mismo costo. ¿Es eso correcto o hay algún conocimiento del rendimiento del almacenamiento que se tiene en cuenta?

En un ejemplo totalmente artificial, digamos que las filas de mi tabla se almacenan en una unidad SSD en mi SAN con tiempos de acceso instantáneos, donde mis índices se almacenan en unidades SAS que están extremadamente sobrecargadas, lo que resulta en saturación de disco y colas de disco constantes. Cuando el RDBMS genera el plan de ejecución, ¿es más probable que favorezca una exploración de tabla que una operación de índice (o posiblemente un índice reducido y búsquedas de tabla asociadas, en lugar de un índice de cobertura, porque es menos IO en los discos SAS)?

Sospecho que la respuesta es un sólido "no es una posibilidad que el optimizador sea inteligente o incluso consciente del rendimiento del disco", pero solo quería ver si alguien por ahí lo sabe con seguridad. Estoy usando SQL Server, pero estoy interesado en cualquier sistema de base de datos.

El optimizador de consultas del servidor SQL no tiene en cuenta las variaciones en el rendimiento del disco al compilar un plan de consulta. Paul White proporciona una excelente descripción general del optimizador basado en costos de SQL Server aquí:

https://sqlkiwi.blogspot.com/2010/09/inside-the-optimizer-plan-costing.html

Algunos puntos clave son:

• El optimizador no está tratando de calcular el costo exacto de un plan. Está tratando de elegir el plan con el costo relativamente más bajo entre varias alternativas.

• Es una visión simplificada de la realidad. Se supone que un servidor puede realizar 320 io / seg y que el rendimiento de la CPU no ha aumentado en más de una década.

• A pesar de que los servidores de hoy en día tienen características de rendimiento muy diferentes, el optimizador todavía hace un buen trabajo en la mayoría de los casos.

Entonces, ¿por qué Microsoft no agrega inteligencia adicional al optimizador? Sin embargo, en el futuro, lo más probable es que sean pequeños ajustes en los costos de los iteradores individuales. Actualmente, el beneficio no existe para justificar el esfuerzo.

Puede usar llamadas dbcc no documentadas para cambiar algunos de los supuestos del optimizador de consultas. NO UTILICE ESTOS EN UN SERVIDOR DE PRODUCCIÓN

DBCC SETIOWEIGHT(<multiplier>)
DBCC SETCPUWEIGHT(<multiplier>)

Ambos tienen valores predeterminados de 1. Juegue con ellos y vea si puede encontrar valores diferentes que produzcan mejores planes de manera consistente en la mayoría de los casos. Descubrirá que los pequeños cambios no cambiarán la mayoría de los planes y los grandes cambios generarán planes realmente extraños.

Un punto adicional es que si bien SQL no considera el rendimiento de io al compilar un plan, sí responde al rendimiento de io durante la ejecución del plan (limitando las lecturas de lectura anticipada si io está saturado, etc.)

El optimizador de consultas Db2 for LUW conoce las características de rendimiento del hardware de la máquina en la que se está ejecutando y las tiene en cuenta.

Específicamente, cada espacio de tabla tiene dos parámetros numéricos que reflejan el rendimiento del almacenamiento subyacente: overheadque refleja la sobrecarga del controlador de E / S y el tiempo de búsqueda y latencia del disco en milisegundos y transferrateque indica el tiempo requerido para transferir una página de espacio de tabla del disco a la memoria.

Estos parámetros se pueden especificar en el momento de creación del espacio de tabla para anular los valores predeterminados derivados heurísticamente.

El cpu_speedoptimizador utiliza los parámetros de rendimiento de E / S, junto con el parámetro de nivel de administrador de base de datos, para calcular el costo de E / S y CPU de cada operador del plan de consulta y, por lo tanto, afectará qué plan se elija en última instancia. Posteriormente, su escenario sería completamente plausible en Db2. De manera similar, en un sistema con una velocidad de CPU muy alta y un rendimiento de disco regular, el optimizador podría preferir operadores intensivos de CPU (por ejemplo, exploración de tablas más clasificación) a operadores más intensivos de E / S (por ejemplo, acceso a tablas basado en índices).

Creo que Db2 para z / OS también tiene en cuenta las características subyacentes de rendimiento del hardware, obteniéndolas de la capa de administración de almacenamiento, no como parte de la configuración de la base de datos.