Query optimizationEn nuestro anterior artículo hablamos sobre las grandes ventajas de aplicar buenas prácticas de programación contra SQL Server. Queremos seguir profundizando en ello, centrándonos esta vez en la optimización de consultas.

El SQL es un lenguaje declarativo: cada consulta declara qué queremos que haga el motor de base de datos (BD), pero no dice cómo. Sin embargo, resulta que ese “cómo” (el plan), es lo que afecta a la eficiencia de las consultas, por lo que también es bastante importante.

¿Qué es la optimización de consultas?

La optimización de consultas es un tema denso que podría volverse pesado fácilmente. La mejor manera de abordar un problema de rendimiento es encontrar áreas específicas donde poner el foco. Buscar cosas concretas que probablemente sean causa de una alta latencia. En estos escenarios, encontrar código sospechoso de consumir muchos recursos puede acotar rápidamente la búsqueda y permitirnos resolver un problema en lugar de vernos obligados a investigar cada línea de código.

La clave es ir identificando patrones de diseño comunes que sean indicativos de un código Transact-SQL de bajo rendimiento. El desarrollo del reconocimiento de estos patrones, de detectar errores, puede permitirnos enfocarnos inmediatamente en lo que es más probable que sea el problema.

La optimización de consultas a veces requiere recursos adicionales, como puede ser agregar un nuevo índice. Pero cuando podemos mejorar el rendimiento únicamente reescribiendo una consulta, reducimos el consumo de recursos sin ningún coste, aparte de nuestro tiempo. Como resultado, la optimización de consultas puede ser una fuente directa de ahorro de costos. Y más aún si conseguimos, mediante el uso de buenas prácticas, crear desde el inicio las consultas de la forma más eficiente posible.

A la hora de probar consultas y medir mejoras de rendimiento, un error común es ejecutarlas en un ambiente de desarrollo cuando el sistema no está ejecutando diferentes consultas de otros usuarios y donde suele haber muy pocos registros. Todo se ejecuta rápidamente porque no hay carga en el servidor de bases de datos de desarrollo. Pero después, no suele reservarse tiempo suficiente para las pruebas en otros ambientes. Los entornos de calidad y testing acaban siendo meros protocolos de transición hacia una subida a producción, en el mejor de los casos. Al final, una vez en explotación el nuevo código, si algo no va bien se excusa con la típica frase: “No sé cómo puede ir tan lento, a mí antes me funcionaba rápido y bien”.

Cuando una consulta de las anteriores se promueve a un entorno de producción y se ejecuta en un entorno ocupado, la consulta puede funcionar mal y socavar el rendimiento de la aplicación. Si en el anterior artículo veíamos la importancia de dominar nuestro modelo de BD como principal habilidad, aquí tenemos la segunda (y obligatoria) buena práctica: Siempre hay que vigilar y probar el rendimiento, siempre, incluso si la consulta parece que no va a necesitar emplear muchos recursos del Servidor de base de datos.

Por eso, cuando desarrollamos, antes de integrar nuestras consultas en el código de la aplicación, es muy recomendable utilizar los Entornos de Desarrollo Integrados (IDE’s) para BBDD relacionales. Por ejemplo, Microsoft SQL Server Management Studio que funciona bien para usuarios de Windows, o Azure Data Studio para Windows, MacOS y Linux.

En Teldat seguimos mejorando cada día al aplicar las buenas prácticas para nuestros desarrollos contra BBDD SQL Server en la nube.


Sobre el autor

Fernando Tomas Rodriguez
Fernando Tomas Rodriguez
Ingeniero Técnico en Informática de Sistemas en el departamento de I+D de Teldat. Dentro de dicho departamento trabaja en el grupo de Infraestructura como especialista en Bases de Datos.

Comparte este post


Nuestras Soluciones Relevantes