Una de las mejores partes del lenguaje SQL es que es fácil de aprender y seguir los comandos, todo ello gracias a su sencilla sintaxis.

Pero aquí está la trampa: no todas las funciones de la base de datos son eficientes. Dos consultas pueden parecer similares, pero varían en cuanto al tiempo de cálculo, y esto es lo que marca la diferencia. Por este motivo, el ajuste de las consultas SQL es esencial.

Si usted es una organización que utiliza una base de datos de producción en vivo para la elaboración de informes y la extracción de datos actualizados, es incluso importante optimizar las consultas SQL para evitar poner una carga innecesaria en los recursos de la base de datos de producción.

Modo de ajustar sus consultas SQL

Tenga un conjunto claro de requisitos empresariales antes de empezar

Una de las mejores maneras de optimizar las consultas SQL es haciendo las cosas correctas desde el principio. Por lo tanto, antes de comenzar, asegúrese de haber marcado las siguientes casillas:

¿Ha reconocido a las partes interesadas relevantes?

Es esencial involucrar a todas las personas y equipos relevantes mientras se desarrolla la consulta. Además, es incluso importante involucrar al equipo de DBA mientras se consultan las bases de datos de producción.

¿Ha identificado sus requisitos?

La mejor práctica para garantizar que se cumplen todos sus requisitos es responder a 5 conjuntos de preguntas – ¿Quién? ¿Por qué? ¿Qué? ¿Cuándo? ¿Dónde?

¿Son los requisitos identificados específicos y al punto?

La base de datos de producción juega un papel crucial. Gravar la base de datos con requisitos ambiguos es demasiado arriesgado. Por lo tanto, antes de ejecutar una consulta, asegúrese de que todos los requisitos son específicos, y discutidos con las partes interesadas apropiadas

Dominar el arte de la creación de índices correctamente

El ajuste del rendimiento en SQL se puede hacer mediante la indexación adecuada, lo que se traduce en un acceso más rápido a la base de datos durante los momentos críticos. Esta es un área donde la mayoría de los novatos en bases de datos se quedan cortos. Intentan indexar todo o no indexar nada, y ninguno de estos enfoques funciona a su favor.

Esto se debe a que cuando no se hace ningún tipo de indexación, las consultas se ejecutarán lentamente y pondrán una carga innecesaria en la base de datos. Por otro lado, si indexas todo, tus desencadenantes de inserción no funcionarán como se espera, haciendo así que tu base de datos sea ineficiente. La clave aquí es encontrar el equilibrio adecuado.

Evitar el uso de SELECT*

SELECT* (leído como select all) se utiliza a menudo como una abreviatura para consultar todos los datos de una tabla. Aunque este método funciona bien para las tablas más pequeñas, carga innecesariamente los recursos de la base de datos cuando se dispara una consulta en una tabla con muchos campos y filas.

La mejor manera en este caso es definir los campos en la sentencia SELECT para ordenar a la base de datos que consulte sólo los datos necesarios para cumplir con los objetivos finales.

Entendamos mejor esto con la ayuda de un ejemplo:

Aquí hay una forma ineficiente ya que esta consulta obtendrá todos los datos almacenados en la tabla Usuarios independientemente de sus necesidades.

SELECT*

FROM Users

Esta es la forma más eficiente de consultar ya que extrae sólo la información necesaria y evita que tu base de datos se sobrecargue.

SELECT LastName, Address, Contact

FROM Users

Utiliza las tablas temporales con prudencia

Aunque las tablas temporales son estupendas, aumentan exponencialmente la complejidad de una consulta. Es muy recomendable evitar el uso de tablas temporales si su código puede ser escrito de forma sencilla.

Sin embargo, si necesita tratar con un procedimiento almacenado que no puede ser manejado con una sola consulta, el uso de tablas temporales como intermediarios puede poner fin a sus problemas.

Evite el uso de COUNT()

Una de las formas comunes a través de las cuales los desarrolladores comprueban si un determinado registro existe es mediante el uso de COUNT() en lugar de EXISTS(). COUNT() es ineficiente porque escanea toda la tabla y cuenta todas las consultas que satisfacen su condición. Por otro lado, EXISTS() es más eficiente ya que sale del bucle tan pronto como encuentra el resultado deseado. Esto contribuye a un mejor funcionamiento, y da paso a un código más ordenado.

Evite el uso de caracteres comodín al principio del patrón LIKE

Para afinar sus consultas SQL, debe evitar el uso del patrón LIKE de la siguiente manera:

SELECT* FROM Customers WHERE address LIKE ‘%bar%’;

Aquí, la base de datos no podrá utilizar un índice adecuado si existe debido al % comodín. El sistema comienza realizando un escaneo completo de la tabla y esto hace mella en su velocidad. Por lo tanto, la mejor manera de escribir esta consulta es:

SELECT* FROM Customers WHERE address LIKE ‘bar%’;

Evitar el uso de SELECT DISTINCT

Aunque se pueden eliminar fácilmente los duplicados de una consulta utilizando SELECT DISTINCT, esta función consume una cantidad apreciable de potencia de procesamiento. Además, esta consulta funciona agrupando todos los campos de la consulta para presentar resultados distintos. Esto, a su vez, hace que sea muy inexacta.

La mejor manera de evitar cualquier registro duplicado en su consulta es añadiendo más campos. De esta manera, no será necesario agrupar y los registros obtenidos serán precisos.

Por ejemplo, esta es una forma ineficiente de hacerlo:

SELECT DISTINCT FirstName, LastName, State

FROM Users

Y esta es la forma eficiente de hacerlo:

SELECT FirstName, LastName, Contact, Address, State, Zip

FROM Users

Consejo extra: Guarda algunas consultas para las horas valle

Para asegurar que tu base de datos de producción se mantiene segura y sólida, es muy recomendable programar ciertas consultas para las horas valle, idealmente cuando el número de usuarios concurrentes es menor. Así, la mitad de la noche, de 3 a 5 de la mañana es el mejor momento para ejecutar consultas como:

• Instrucciones en bucle
• Ejecutar SELECT* en tablas grandes con más de 1 millón de registros
• Subconsultas anidadas
• Búsquedas con tarjeta comodín
• .
• CROSS JOINs
• Sentencias SELECT DISTINCT

El resumen

El ajuste del rendimiento en SQL es importante para mantener su base de datos saludable, pero no es la tarea más fácil de realizar. El rendimiento de sus consultas SQL depende de una serie de factores como su modelo de base de datos, el tipo de información que necesita para obtener y así sucesivamente.

Es muy recomendable para evitar cualquier situación incómoda por mantener un seguimiento de todas las consultas que pronto se va a disparar, y proporcionar las mejores soluciones. Como DBA, también podría equipar a los desarrolladores con un panel de control basado en datos de tal manera que no tengan que disparar consultas de vez en cuando para obtener la información esencial. Aquí hay un artículo increíble sobre cómo se puede crear un tablero de instrumentos SQL que tira de los datos directamente de la base de datos.

¿Cuál es su opinión sobre esto? Cómo afinas tus consultas SQL? Háganoslo saber.