Un compañero de trabajo que es un crack en temas de optimización de bases de datos me ha pasado la siguiente información. Cuando hacemos una consulta con un LIMIT x, y sobre una tabla con millones de registros, a medida que x aumenta, la consulta se va haciendo cada vez más lenta. Veamos un ejemplo:

SELECT version FROM car LIMIT 300,100; (100 results, 0.01 sec)

SELECT version FROM car LIMIT 3000000,100; (100 results, 2.5 sec)

Si además agregamos un par de JOINS a esta consulta, la complicamos un poco y le añadimos un ORDER BY, los problemas de rendimiento pueden llegar a causar un colapso en la base de datos.

¿Por qué pasa esto?

Para determinar el primer valor que tiene que seleccionar, MySQL debe recorrer desde el primer registro e ir contando hasta llegar al 300, a partir de ahí, cogerá 100. Obviamente, a medida que el valor de X va aumentando, la búsqueda del primer elemento es más lenta y como podemos ver en el ejemplo de arriba, llega a tardar 2,5 segundos en recorrer 3.000.000 de registros.

¿Cómo lo podemos solucionar?

Mi compañero propone hacer la búsqueda acotando a partir de primary key de la tabla, de este modo, al ser un campo indexado la búsqueda es realmente eficiente y nos evitamos cargar la máquina:

SELECT version FROM car WHERE id_car BETWEEN 3000000 AND 3000100; (~100 results, 0.01 sec)

Esta solución no nos sería válida a la hora de construir un paginador, porque en el caso de tener vehículos desactivados u eliminados, unas páginas contendrían 100 vehículos, otras quizá 74… sin embargo, si por ejemplo construimos un script que se recorra toda la tabla car esta es una buena manera de realizar la búsqueda.

Explain es una potente herramienta que MySQL pone a nuestra disposición para orientarnos sobre como está ejecutando una consulta el motor de la base de datos.

Esto nos es de mucha utilidad cuando creamos una consulta nueva, pues nos indica que índices va a utilizar, de que tipo son, como de efectiva será la respuesta al usar esos índices… por lo tanto, podemos detectar rápidamente, por ejemplo, de que nuestra consulta no está bien formada o que nos falta un índice en algún campo concreto.

Si ejecutamos la siguiente consulta:

EXPLAIN SELECT *
FROM user u
INNER JOIN user_profile up ON u.id = up.user_id

Obtendremos una respuesta como esta:

Pero, ¿qué quieren decir estas columnas? ¿qué información nos dan?

1. Table: Nos informa de la tabla a la que nos estamos refiriendo.
2. Type: El tipo de unión que se está usando. Desde la mejor hasta la peor, los tipos de uniones son system, const, eq_ref, ref, range, index, y ALL.
   • System: Tabla con una única fila, por tanto, la respuesta es inmediata.
   • Const: En la tabla coincide una única fila con los criterios indicados. Al sólo haber una fila, el optimizador toma este valor como constante, por este motivo este tipo de tablas son muy rápidas.
   • Eq_ref: Una fila de la tabla 1 será leída por cada combinación de filas de la tabla 2. Este tipo es usado cuando todas las partes de un índice se usan en la consulta y el índice es UNIQUE o PRIMARY KEY.
   • Ref: Todas las filas con valores en el índice que coincidan serán leídos desde esta tabla por cada combinación de filas de las tablas previas. Similar a eq_ref, pero usado cuando usa sólo un prefijo más a la izquierda de la clave o si la clave no es UNIQUE o PRIMARY KEY. Si la clave que es usada coincide sólo con pocas filas, esta union es buena.
   • Range: Sólo serán recuperadas las filas que estén en un rango dado, usando un índice para seleccionar las filas. La columna key indica cual índice es usado, y el valor key_len contiene la parte más grande de la clave que fue usada. La columna ref será NULL para este tipo.
   • Index: Escaneo completo de la tabla para cada combinación de filas de las tablas previas, revisando únicamente el índice.
   • ALL: Escaneo completo de la tabla para cada combinación de filas. Es el peor caso ya que revisará todas las filas para cada combinación.
3. Possible_keys: Posibles indices que utilizará la consulta.
4. Key: Índice utilizado para ejecutar la consulta. Si indica el valor NULL, no se ha escogido ningún índice.
5. Key_len: Cuanto más pequeño sea este valor, más rápida será la consulta, pues nos indica la longitud del índice usado.
6. Ref: Las columnas del índice que se está usando, o una constante si esta es posible.
7. Rows: Número de filas que MySQL debe analizar para devolver los datos solicitados.
8. Extra: Información complementaria sobre como MySQL ejecutará la consulta. Los posibles valores en este campo pueden ser:
   • Distinct: MySQL ha encontrado una fila coincidente con los filtros indicados y no necesita seguir analizando.
   • Not exists: MySQL fue capaz de hacer una optimización LEFT JOIN sobre la consulta y no examinará más filas en la tabla para la combinación de filas previa después de que encuentre una fila que coincida con el criterio LEFT JOIN.
   • Range checked for each record: No se encontró un índice válido. Para cada combinación de filas se hará un chequeo para determinar que indice utilizar y en caso de encontrar alguno válido, lo utilizará.
   • Using filesort: Este valor indica que MySQL necesita hacer un paso extra para encontrar la forma de ordenar las filas. Este tipo de consultas debe ser optimizada.
   • Using index: Recupera la información solicitada utilizando únicamente la información del índice. Esto sucede cuando todas las columnas requeridas forman parte del índice.
   • Using temporary: Para resolver esta consulta, MySQL creará una tabla temporal. Uno de los casos típicos en los que devuelve este valor es cuando usamos un ORDER BY sobre un conjunto de columnas diferentes a las indicadas en la clausula GROUP BY. Este tipo de consultas debe ser optimizada.
   • Where used: Se usará una clausula WHERE para determinar que filas serán comparadas con otra tabla. Si no deseamos regresar todas las filas desde la tabla, y el join es del tipo ALL o index, es muy probable que hayamos escrito algo mal en la consulta.

   Una respuesta en este campo del tipo “Using filesort” o “Using temporary” es susceptible de ser una consulta a optimizar.

Si analizamos la consulta ejecutada anteriormente,vemos que para la tabla con alias ‘up’ está utilizando el tipo de unión `ALL` debido a que no existe ningun filtro en la clausula WHERE (en este caso, es normal ya que queremos devolver todos los valores). Se podría utilizar el índice existente `user_id_idx` pero al no haber ningún filtro, no es necesario usarlo. Para devolver esta consulta MySQL analizará 13 filas.

La segunda fila hace referencia a la tabla con alias ‘u’. Utiliza un tipo de unión `eq_ref` ya que devolverá una fila para cada fila de la tabla `up` pudiendo usar y usando el índice primario de la tabla que tiene una longitud de 4 (muy pequeño). Se está utilizando la columna `user_id` del índice de la tabla `up` y de la base de datos `futbol` analizando una única fila para cada fila de la tabla contigua.

Todos los valores son correctos y podemos asegurar que esta consulta está optimizada!!

Muchas veces nos encontramos con la necesidad de crear un campo autoincremental en una tabla de nuestra base de datos. Típicamente suele usarse para generar una clave primaria para dicha tabla. Pues bien, la primera vez que nos enfrentamos con esta situación trabajando con Oracle, nos encontraremos con un grave problema que nos puede hacer perder mucho tiempo, puesto que, aunque parezca mentira, no existe ningún tipo de campo autoincremental en Oracle.

La solución es bastante sencilla (aunque no por ello deja de ser incómodo no disponer de un campo de este tipo directamente). Oracle dispone de un tipo de objeto denominado secuencia (SEQUENCE). Una secuencia tiene un valor inicial, un valor máximo y un valor de secuencia que incrementará cada vez que hagamos una llamada a la secuencia.

La estructura para crear una secuencia es la siguiente:

CREATE SEQUENCE sequence_name
MINVALUE value
MAXVALUE value
START WITH value
INCREMENT BY value
CACHE value / NOCACHE;

Donde:

• MINVALUE es el valor mínimo que tendrá la secuencia (usualmente 0 o 1)
• MAXVALUE es el valor máximo que tendrá la secuencia (se puede obviar y por defecto se le asignará 999999999999999999999999999)
• START WITH es el valor con el que empezará la secuencia
• INCREMENT BY es el valor con el que se incrementará la secuencia (usualmente 1, pero podríamos usar 2 para generar solo valores pares por ejemplo [siempre y cuando hubiesemos puesto el campo anterior a 0 o 2 ] )
• CACHE / NOCACHE el uso de CACHE permite indicar cuantos valores queremos que sean guardados en memoria para una acceso más rápido. El inconveniente que tiene es que en caso de una caida del sistema, los valores generados por la secuencia se pierden y quedarian “huecos”.

Una vez creada la secuencia la usaremos llamando a sequence_name.nextval. Por ejemplo:

INSERT INTO mi_tabla (tabla_id, tabla_campo1) VALUES (mi_secuencia.nextval, ‘valor1′);

También podremos acceder al valor de la secuencia en una consulta haciendo la siguiente llamada (hay que tener en cuenta que esta llamada también nos incrementará el contador de la secuencia):

SELECT sequence_name.nextval FROM dual;

Por último veremos como podemos modificar el valor de la secuencia para asignarle uno arbitráriamente. Primero modificaremos la secuencia indicándole que a partir de este momento cada vez que sea llamada incremente su contador en tantas posiciones como la diferencia entre el valor que queremos asignarle (p.ej. si nuestra secuencia tiene valor 327 y queremos asignarle el 450, deberemos incrementar en 123).

ALTER SEQUENCE seq_name INCREMENT BY 123;

Luego haremos una llamada a la secuencia para que se incremente con el nuevo valor:

SELECT seq_name.nextval FROM dual;

Y por último volveremos a alterar la secuencia para que vuelva a incrementar igual que antes (en nuestro ejemplo de uno en uno)

ALTER SEQUENCE seq_name INCREMENT BY 1;

También existe la posibilidad de generar campos autoincrementales creando un trigger que sea llamado antes de la inserción y se encargue de calcular el siguiente valor libre. O haciendo una consulta previa del primer valor libre del campo. Pero son técnicas más engorrosas y que pueden dar lugar a errores y problemas con más facilidad de la expuesta aquí.