Pildoritas de Bases de Datos: Optimización. Consideraciones de rendimiento de los operadores

¡Sorpresa! Sí, tras tan sólo una semana de espera vuelven de nuevo las Pildoritas de Bases de Datos. La pildorita de hoy está dedicada a consideraciones de rendimiento de los operadoresOH, WAIT!

Si, dije que primero veríamos los WHERE SARGABLE, pero también que me estaba costando horrores organizarme las ideas y que no era definitivo (ya me imaginaba que esto podía ocurrir xD), así que sintiéndolo mucho, tendréis que esperar un poco más para salir de dudas con el tema del WHERE SARGABLE (culpa vuestra por no haberlo buscado ya 😀 )

Que conste que comencé con el tema de NON-SARGABLE primero, pero al ver que había temas que se me iban a mezclar con los operadores, no me quedó más remedio que darle la vuelta a la idea inicial y comenzar por éste tema.

Como decía (ya me empiezo a liar), en esta pildorita veremos cuestiones sobre el rendimiento de los operadores y posibles alternativas para evitar utilizar aquellos más costosos.

Tanto en esta pildorita como la siguiente hay que tener siempre claro que muchas de estas pautas no son más que simples consejos. La optimización es todo un mundo y muchas veces las pautas típicas de nada sirven y hasta es posible que lo contrario a lo que pensábamos sea la solución. En estos dos temas intentaré dejar siempre claro que esto no son reglas absolutas, pero me gustaría destacarlo para que así lo tengamos siempre presente.

Bueno, no me enrollo más, al lío xD

Rendimiento de operadores en el WHERE

Como decía hace un momento, el rendimiento de los operadores puede variar en cada consulta, pero se pueden clasificar de mejor a peor rendimiento de la siguiente forma:

  • =
  • >, >=, <, <=
  • LIKE
  • <>

A parte del operador en sí, también repercuten en el rendimiento otras cuestiones como el tipo de los operandos utilizados, el orden de estos, etc.

Ordenadas de mejor a peor rendimiento, estas son las otras pautas que también hay que tener en cuenta con respecto a los operadores:

  • Utilizar un literal único en lugar de varios
  • Utilizar un nombre de columna o un parámetro
  • Una expresión multiperando
  • Un número único exacto
  • Un número único no exacto al lado de un operador (date, time)
  • Datos de caracteres o NULL.

No obstante, esto pocas veces tiene mucha importancia ya que no es aplicable cuando el WHERE contiene más de una expresión, así que estos consejos rara vez podrán solucionaros la vida.

Operador IN

Siempre que podamos intentaremos sustituir este operador por cualquiera de las siguientes opciones.

EXISTS

NOT EXISTS, al estar conjugado con el operador NOT es NON-SARGABLE (por ahora sólo basta con saber que es malo xD), pero pese a ello su rendimiento es mejor que el IN muchas veces. Otras veces lo mejor es variar por IN utilizando el conjunto complementario de elementos, o en caso de que sea sólo un caso el comando EXISTS con esos complementarios, ya que es mucho más eficiente que el IN.

Vamos a verlo una vez más con un ejemplo. Imaginemos que queremos ver los datos de empleado de aquellos que no tengan proyecto.

SELECT NOMBRE, APELLIDOS, DNI, TELEFONO, ID_PUESTO, ID_COMPAÑIA 
FROM EMPLEADO WHERE ID_EMPLEADO NOT IN (
SELECT ID_EMPLEADO FROM EMPLEO_HAS_PROYECTO_HAS_DEPARTAMENTO
)

Esta query es transformable a:

SELECT NOMBRE, APELLIDOS, DNI, TELEFONO, ID_PUESTO, ID_COMPAÑIA 
FROM EMPLEADO 
WHERE ID_EMPLEADO EXISTS (
SELECT ID_EMPLEADO FROM EMPLEO_HAS_PROYECTO_HAS_DEPARTAMENTO
)

LEFT OUTER JOIN y chequear por la condición (si es un NOT IN se mirará que sea NULL)

La otra forma de convertir esta query es con un LEFT OUTER JOIN, chequeando que ese campo sea NULL.

De nuevo veamos con el mismo ejemplo la conversión a través del LEFT OUTER JOIN:

SELECT EMP.NOMBRE, EMP.APELLIDOS, EMP.DNI, 
EMP.TELEFONO, EMP.ID_PUESTO, EMP.ID_COMPAÑIA 
FROM EMPLEADO EMP LEFT JOIN EMPLEO_HAS_PROYECTO_HAS_DEPARTAMENTO EPD 
ON EMP.ID_EMPLEADO = EPD.ID_EMPLEADO 
WHERE EMP.ID_EMPLEADO IS NULL

Siempre que queramos comprobar solamente la existencia de un registro utilizaremos el EXISTS en vez del IN.

Si no es viable prescindir del operador IN debemos poner en la parte izquierda los valores más frecuentes de encontrar y al final de la lista los menos frecuentes.

¿Y el operador BETWEEN?

El operador BETWEEN comprueba que un valor se encuentre dentro de un rango, por lo que también puede sustituir en muchas ocasiones a la clausula IN y su rendimiento es mucho mejor. Siempre que podamos escoger, utilizaremos el operador BETWEEN.

SELECT ID_DEPARTAMENTO FROM DEPARTAMENTO WHERE ID_DEPARTAMENTO IN (1, 2, 3, 4)

Por:

SELECT ID_DEPARTAMENTO FROM DEPARTAMENTO WHERE ID_DEPARTAMENTO BETWEEN 1 AND 4

En el caso de que ID_DEPARTAMENTO tenga un índice (cosa casi segura porque es PK), al motor le resultará mucho más fácil calcular el resultado a través del operador BETWEEN.

Utilización del operador LIKE

Cuando utilicemos el operador LIKE debemos de intentar que nuestra cadena de búsqueda no comience jamás por una wildcard (%, *, etc), ya que en estos casos el operador no puede utilizar su índice, lo que le convierte en una clausula NON-SARGABLE y aumenta mucho más su coste.

Operador OR

En la primera pildorita os decíamos que una posible modificación para el UNION era usar OR, pero esto no siempre es verdad. Algunos motores de Bases de Datos como MySQL no utilizan los índices cuando hay operadores OR, por lo que a veces es mejor utilizar un UNION ALL a un OR.

Si tenéis dudas, lo mejor es tirar ambas queries y ver si vuestra tecnología tiene problemas de rendimiento con el OR.

Índice de Pildoritas

Share