de Martin LE TARNEC.

Impactos sobre el rendimiento de la carga del sistema


El estudio de la manera de definir un índice multi-columna se detiene generalmente tan pronto como el índice sea utilizado por la sentencia ya optimizada. Sin embargo, el optimizador no utiliza el índice porque sea el "correcto" para la sentencia, sino porque por supuesto es más eficiente que un escaneo entero de la tabla. Eso no significa que sea el índice óptimo para la sentencia.

El ejemplo anterior nos muestra las dificultades que surgen a la hora de identificar un orden de columnas incorrecto en un plan de ejecución. Muy seguido, la información de los predicados está bien escondida así que se debe buscar por ellos sobre todo para validar el uso óptimo de los índices.

Por ejemplo, SQL Server Management Studio muestra solamente la información de los predicados como una herramienta de ayuda cuando se mueve el cursor ("hover") sobre la operación del índice también en esta página web. El siguiente plan de ejecución usa el índice SCALE_SLOW; nos muestra la condición sobre ID2 como un predicado de filtro (solamente "Predicate", sin "Seek").

Obtener la información de los predicados desde un plan de ejecución MySQL o PostgreSQL es generalmente más complicado. El Apéndice A tiene los detalles.

No importa lo insignificante que parezca la información de los predicados en el plan de ejecución: tiene un gran impacto sobre el rendimiento, especialmente cuando el sistema crezca. Recuerda que no es solamente el volumen de datos el que crece, sino también la tasa de acceso. Ya es otro parámetro de la función de escalabilidad.

La Figura 3.4 muestra el tiempo de respuesta como una función de la tasa de acceso. El volumen de datos sigue sin cambiar. Se despliega el tiempo de ejecución de la misma sentencia como antes y usa siempre la sección con el mayor volumen de datos. Eso significa que el último punto de la Figura 3.2 corresponde al primer punto en esta gráfica.

Figura 3.4 Escalabilidad en un sistema cargado

La línea discontinua marca el tiempo de respuesta cuando se usa el índice SCALE_SLOW. Crece hasta 32 segundos si existen 25 sentencias ejecutándose al mismo tiempo. En comparación con el tiempo de respuesta sin carga concurrente, como debería ser el caso en un ambiente de desarrollo, lleva 30 veces más. Así que aunque se tenga una copia completa de la base de datos de producción en el entorno de desarrollo, la carga concurrente puede causar incluso que una sentencia se ejecute más lentamente en producción.

La línea recta muestra el tiempo de respuesta usando el índice SCALE_FAST, sin predicados de filtro. El tiempo de respuesta queda por debajo de 2 segundos aunque haya 25 sentencias ejecutándose simultáneamente.

Nota

Ojo, la revisión del plan de ejecución brinda más confianza que puntos de referencia superficiales.

Las pruebas de estrés son muy útiles, aunque su costo sea muy alto.

Los tiempos de respuesta sospechosos generalmente se toman a la ligera durante la fase de desarrollo. Esto es así en gran parte porque se espera que el "hardware más poderoso de producción" entregue mejor rendimiento. Sin embargo, con frecuencia no ocurre así, sino más bien lo contrario porque la infraestructura de producción es más compleja y acumula latencias que no existen en el ambiente de desarrollo. Incluso cuando se prueba en una infraestructura equivalente, la carga de fondo puede causar tiempos de respuesta diferentes. En la siguiente sección se va a ver que, por lo general, no es razonable esperar tiempos de respuestas más rápidos con un "hardware más grande".

Si te gusta mi manera de explicar, te encantará mi libro.

Ver también

Acerca del autor

Foto de Markus Winand

Markus Winand enseña eficientemente SQL, en casa y online. Minimiza el tiempo de desarrollo utilizando moderno SQL y optimiza el tiempo de ejecución con indexación inteligente. Para ello también ha publicado el libro SQL Performance Explained.

“Use The Index, Luke” de Markus Winand se halla bajo licencia Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License.
Aspectos legales | Contacto | SIN GARANTÍA | Marcas | Privacy | CC-BY-NC-ND 3.0 licencia