Lesión 10.2 · Tiempo de lectura: ~10 min

Esta lección introduce los fundamentos de la escritura de consultas SQL de alto rendimiento. Aprenderás cómo evitar una carga innecesaria en la base de datos, por qué SELECT * a menudo perjudica el rendimiento y cómo filtrar datos de manera efectiva. Revisaremos técnicas prácticas que ayudan a que las consultas se ejecuten más rápido, incluso en conjuntos de datos grandes. Al final de esta lección, podrás escribir SQL eficiente que utilice los recursos del servidor de manera responsable.

Lección 10.2: Escribiendo Consultas SQL Eficientes

En la lección anterior, nos enfocamos en la legibilidad para las personas. Pero SQL también debe ser legible y eficiente para el motor de la base de datos. Incluso un código perfectamente formateado puede tener un rendimiento deficiente si obliga al servidor a realizar trabajo innecesario.

La eficiencia de la consulta afecta directamente la velocidad de la aplicación y los informes. En sistemas de grandes datos o alta carga, la diferencia entre "funciona" y "optimizado" puede ser minutos o incluso horas de tiempo de ejecución.

Los motores de DBMS modernos tienen optimizadores potentes que pueden reescribir consultas en segundo plano. Sin embargo, un optimizador no es todopoderoso. No conoce tu intención comercial y no siempre puede corregir decisiones de diseño fundamentalmente ineficientes. La calidad del código sigue siendo responsabilidad del desarrollador.

Regla de oro: recupera solo lo que necesitas

La razón más común para consultas lentas es mover demasiados datos innecesarios entre el servidor de la base de datos y el cliente.

Evita SELECT *

Si bien SELECT * es conveniente para una exploración rápida, evítalo en SQL de producción.

• Tráfico extra: transfieres columnas que no necesitas.
• Limitaciones de índice: las estrategias de índice cubriente se vuelven más difíciles cuando se solicitan todas las columnas.
• Código frágil: agregar una nueva columna puede cambiar inesperadamente el comportamiento y el rendimiento.

-- Pobre
SELECT * FROM film;

-- Mejor
SELECT film_id, title, release_year
FROM film;

Optimización del filtrado

Cómo limites las filas determina cuánto dato debe escanear y procesar el DBMS.

Filtra en el lado del servidor

Aplica condiciones WHERE tan pronto como sea posible, antes de una agregación pesada o retorno a los clientes. Cuanto antes reduzcas las filas, más rápidas serán las etapas posteriores (JOIN, GROUP BY).

Evita funciones en WHERE (consultas SARGable)

Para usar índices de manera efectiva, los predicados WHERE deben ser SARGable (Search ARGumentable). Si envuelves una columna indexada en una función, el optimizador a menudo no puede usar el índice de manera eficiente y puede escanear toda la tabla.

-- Lento (No SARGable: el índice en rental_date puede no ser utilizado)
SELECT count(*) 
FROM rental 
WHERE YEAR(rental_date) = 2005;

-- Rápido (SARGable: se puede usar el índice)
SELECT count(*) 
FROM rental 
WHERE rental_date >= '2005-01-01' AND rental_date < '2006-01-01';

Trabajando con JOIN

Unir tablas es una de las operaciones de consulta más intensivas en recursos.

• Filtra primero, une después: reduce el volumen de filas en las tablas secundarias antes de unir.
• Verifica índices en las claves de unión: típicamente claves primarias y foráneas.
• Evita CROSS JOIN innecesarios: los productos cartesianos pueden explotar rápidamente.
• Usa EXISTS para verificaciones de existencia: si solo necesitas saber si existen filas relacionadas, EXISTS suele ser más barato que JOIN.

-- Menos eficiente (JOIN obliga a coincidir a través de todos los pagos)
SELECT DISTINCT c.first_name, c.last_name
FROM customer c
JOIN payment p ON c.customer_id = p.customer_id;

-- Más eficiente (EXISTS puede detenerse en la primera coincidencia)
SELECT c.first_name, c.last_name
FROM customer c
WHERE EXISTS (
    SELECT 1 FROM payment p WHERE p.customer_id = c.customer_id
);

Usa LIMIT mientras pruebas

Al depurar una consulta, siempre usa LIMIT para evitar devolver accidentalmente millones de filas.

SELECT customer_id, first_name, last_name
FROM customer
WHERE active = 1
LIMIT 10;

Ejemplo práctico: optimización de informes

Supongamos que necesitamos películas alquiladas más de 30 veces, limitadas a una categoría.

Enfoque menos eficiente:

SELECT f.title, COUNT(r.rental_id)
FROM film f
JOIN inventory i ON f.film_id = i.film_id
JOIN rental r ON i.inventory_id = r.inventory_id
JOIN film_category fc ON f.film_id = fc.film_id
JOIN category c ON fc.category_id = c.category_id
WHERE c.name = 'Action'
GROUP BY f.title
HAVING COUNT(r.rental_id) > 30;

Enfoque más eficiente: Si conocemos el ID de la categoría, podemos omitir la unión de la búsqueda del nombre de la categoría.

SELECT f.title, COUNT(r.rental_id) AS rental_count
FROM film f
JOIN film_category fc ON f.film_id = fc.film_id
JOIN inventory i ON f.film_id = i.film_id
JOIN rental r ON i.inventory_id = r.inventory_id
WHERE fc.category_id = 1 -- Usa ID en lugar de búsqueda de cadena
GROUP BY f.film_id, f.title
HAVING COUNT(r.rental_id) > 30;

Nota: filtrar por IDs numéricos suele ser más rápido que filtrar por nombres de texto y a menudo permite menos uniones.

Conclusiones clave de esta lección:

• Evita SELECT * en consultas de producción; lista solo las columnas necesarias.
• Filtra tan pronto como sea posible usando WHERE.
• Escribe predicados SARGable para que se puedan usar índices.
• Prefiere EXISTS sobre JOIN para verificaciones puras de existencia.
• Usa LIMIT durante la exploración y depuración.
• Prefiere filtrar por claves numéricas en lugar de etiquetas de texto.

Preguntas Frecuentes

¿Por qué es dañino SELECT * en consultas de producción?

Devuelve columnas innecesarias, aumenta el tráfico y puede bloquear planes amigables con índices. Las listas de columnas explícitas son típicamente más rápidas y seguras.

¿Qué significa SARGable en la práctica?

Un predicado SARGable permite la búsqueda basada en índices. Envolver columnas indexadas en funciones a menudo impide el uso eficiente del índice.

¿Cuándo debo usar EXISTS en lugar de JOIN?

Usa EXISTS cuando solo necesitas saber si existen filas relacionadas y no necesitas columnas de la segunda tabla.

Preguntas para Entrevista

¿Cuáles son tus primeros pasos cuando una consulta SQL es lenta?

Verifica si usa SELECT *, revisa la selectividad de WHERE e identifica predicados no SARGable. Luego inspecciona la estrategia de unión y el volumen de filas al principio de la consulta.

¿Por qué el filtrado temprano mejora el rendimiento?

Reduce el número de filas involucradas en uniones, ordenamientos y agregaciones, disminuyendo el costo total del plan.

¿Cómo difieren JOIN y EXISTS desde una perspectiva de rendimiento?

JOIN combina conjuntos de filas y es necesario cuando necesitas columnas de ambos lados. EXISTS suele ser más rápido para verificaciones booleanas de existencia porque puede detenerse en la primera coincidencia.

En la próxima lección, profundizaremos en el análisis de ejecución y veremos cómo los índices aceleran las consultas a nivel físico.

-> Lección 10.3: Comprendiendo los Métodos de Optimización de Consultas