Una consulta que tardó milisegundos el año pasado puede tardar minutos hoy, simplemente porque la tabla creció. La optimización de consultas SQL se trata menos de trucos inteligentes y más de un proceso repetible: descubra qué está haciendo la base de datos, elimine el trabajo desperdiciado y compruebe que haya ayudado.

Probamos cada técnica a continuación en un millón de filas generadas en SQLite 3.50. Los tiempos son los mejores de varias ejecuciones desde una computadora portátil, utilizando una base de datos en memoria. No coincidirán con su sistema, y ​​PostgreSQL, MySQL y SQL Server tienen cada uno sus propios optimizadores y formatos de plan. Concéntrese en el tamaño de cada mejora y en los principios que la sustentan.

Resultados de un vistazo

La configuración de la prueba

CREATE TABLE customers (
  id INTEGER PRIMARY KEY, name TEXT, city TEXT
);
CREATE TABLE orders (
  id INTEGER PRIMARY KEY, customer_id INT, status TEXT,
  created TEXT, total INT, note TEXT
);
-- 50,000 customers and 1,000,000 orders with random values

Un proceso de optimización simple

1. Encuentre las consultas que importan. Utilice registros de consultas lentos o monitoreo. Una consulta de 200 ms que se ejecuta mil veces por minuto puede importar más que un informe mensual de 10 segundos.
2. Lea el plan. Vea lo que realmente está haciendo la base de datos.
3. Cambie una cosa. Agregue un índice o reescriba parte de la consulta.
4. Mida nuevamente, con datos realistas. Un plan de 100 filas de prueba dice muy poco sobre un millón.
5. Míralo a lo largo del tiempo. Los planes pueden cambiar a medida que los datos crecen y las estadísticas cambian.

Leer un plan de ejecución

Un plan de ejecución es la estrategia paso a paso de la base de datos para ejecutar una consulta, incluido qué índices utiliza y en qué orden une las tablas. Prefije una consulta para verla:

Tenga en cuenta que EXPLAIN ANALYZE en PostgreSQL realmente ejecuta la consulta, así que tenga cuidado al usarlo con UPDATE o DELETE. Esto es lo que debe buscar primero:

Un análisis completo no es automáticamente malo. Si una consulta necesita la mayor parte de una tabla pequeña, el escaneo puede ser la opción más rápida. En PostgreSQL EXPLAIN ANALYZE, también compare las filas estimadas con las filas reales. Una gran diferencia a menudo significa que las estadísticas de las tablas están desactualizadas.

Añade el índice correcto

Esta consulta encuentra los pedidos de un cliente:

SELECT id, total FROM orders WHERE customer_id = 123;

Antes de agregar un índice, el plan era un escaneo completo:

SCAN orders
-- 20 rows in 73 ms

Luego agregamos un índice en la columna de filtro:

CREATE INDEX idx_orders_customer ON orders(customer_id);

SEARCH orders USING INDEX idx_orders_customer (customer_id=?)
-- 20 rows in 0.01 ms

Las mismas 20 filas regresaron miles de veces más rápido, porque la base de datos ya no leía un millón de filas para encontrarlas. Ninguna otra técnica en este artículo nos dio una ganancia mayor. Los primeros buenos candidatos son las columnas utilizadas en WHERE, JOIN y ORDER BY, especialmente cuando reducen los resultados a unas pocas filas. Nuestra guía de índices SQL explica cómo funcionan.

No ajuste columnas indexadas en funciones

Aquí hay dos formas de encontrar pedidos de marzo, con un índice en created:

-- Function on the column
SELECT id FROM orders WHERE substr(created, 1, 7) = '2026-03';
-- SCAN orders USING COVERING INDEX idx_orders_created
-- 84,961 rows in 96 ms

-- Plain range
SELECT id FROM orders
WHERE created >= '2026-03-01' AND created < '2026-04-01';
-- SEARCH orders USING COVERING INDEX idx_orders_created (created>? AND created<?)
-- 84,961 rows in 33 ms

Ambos devuelven filas idénticas, pero la primera tardó aproximadamente tres veces más. El plan muestra por qué: con una función en la columna, la base de datos no puede saltar a una posición en el índice ordenado, por lo que tiene que hacer SCAN en cada entrada. La versión de gama puede SEARCH ir directamente al lugar correcto. Una condición que puede utilizar un índice de esta manera se llama sargable.

El mismo problema aparece con estos patrones comunes:

También comprobamos este último. Se produce un comodín inicial SCAN customers, ya que un índice ordenado desde la primera letra no puede ayudar con una coincidencia al final.

Índices compuestos

Cuando una consulta filtra dos columnas, un índice de una sola columna hace solo una parte del trabajo:

SELECT id FROM orders
WHERE status = 'paid'
  AND created >= '2026-03-01' AND created < '2026-03-08';

-- Using only the created index: 6,198 rows in 19 ms

CREATE INDEX idx_status_created ON orders(status, created);

-- SEARCH orders USING COVERING INDEX idx_status_created
--   (status=? AND created>? AND created<?)
-- 6,198 rows in 2.2 ms

El orden de las columnas es muy importante. Un índice en (status, created) funciona como una guía telefónica ordenada por apellido y luego por nombre. Puede buscar solo el apellido, pero no solo el nombre. Nuestra consulta sobre status por sí sola podría utilizar este índice. El filtrado por created por sí solo generalmente no permite utilizarlo de manera eficiente. Como regla general, coloque las columnas probadas con igualdad primero y las columnas de rango después de ellas.

Ese plan también dice índice de cobertura, lo que significa que el índice contenía todo lo que la consulta necesitaba, por lo que no era necesario leer la tabla en sí. Seleccionar solo las columnas que necesita hace que esto sea más probable, lo cual es otra razón para evitarlo SELECT *.

Paginación más rápida

Usar OFFSET para páginas profundas tiene un costo oculto, ya que la base de datos aún tiene que pasar por todas las filas omitidas:

-- Page deep into the results
SELECT id FROM orders ORDER BY id LIMIT 20 OFFSET 500000;
-- 8.1 ms

-- Keyset pagination: continue from the last id seen
SELECT id FROM orders WHERE id > 500000 ORDER BY id LIMIT 20;
-- 0.01 ms

La paginación del conjunto de claves se mantiene rápida sin importar qué tan profundo vayas. También evita que las filas cambien entre páginas cuando se agregan nuevos datos. La desventaja es que los usuarios no pueden pasar directamente a la página 5000, lo que rara vez es una necesidad real. En tablas con filas anchas, o con más filas para omitir, la brecha puede ser mucho mayor que en nuestra prueba.

Escriba consultas más sencillas

• Seleccione solo las columnas que necesita. SELECT * envía más datos y puede evitar que un índice cubra la consulta.
• Filtrar temprano. Utilice WHERE para eliminar filas antes de agruparlas y HAVING solo para condiciones en agregados. Consulte SQL GROUP BY y TENER.
• Utilice LIMIT cuando solo necesite unas pocas filas.
• Prefiera UNION ALL cuando no necesite eliminar duplicados. Nuestra prueba UNION vs UNION ALL muestra lo que eso ahorra.
• Evite DISTINCT innecesario. A menudo se oculta una unión que produce duplicados.
• Utilice EXISTS para comprobar la existencia. Puede detenerse en la primera coincidencia, como explica nuestra guía de subconsultas SQL.
• Esté atento a las consultas N+1. Una consulta por fila en un bucle, generalmente causada por el código de la aplicación, suele ser el verdadero problema. Una única consulta de unión o por lotes puede reemplazar cientos de viajes de ida y vuelta.

Se une

Indexe las columnas a las que se une. Realizamos un informe de gasto total para los clientes en una ciudad y el plan era exactamente lo que esperaba:

SELECT c.name, SUM(o.total)
FROM customers c
JOIN orders o ON o.customer_id = c.id
WHERE c.city = 'Goa'
GROUP BY c.id;

-- SCAN c
-- SEARCH o USING COVERING INDEX idx_cover (customer_id=?)
-- 9,900 rows in 34 ms

Escanea a los clientes y luego utiliza un índice para encontrar los pedidos de cada uno. Sin un índice en orders.customer_id, la base de datos tendría que trabajar mucho más para cada cliente. Un índice de la clave externa es una de las adiciones más comunes y valiosas que puede realizar. Para actualizar su comprensión de los conceptos básicos, consulte Explicación de uniones SQL.

Cuando los índices te cuestan

Los índices no son gratuitos, así que no agregues uno para cada columna:

• Escrituras más lentas. Cada inserción, actualización y eliminación también debe actualizar cada índice.
• Más almacenamiento y memoria. Los índices pueden crecer en tablas grandes.
• Poco beneficio en columnas no selectivas. Un índice en una columna verdadera o falsa puede no ayudar si la mayoría de las filas coinciden.
• Redundancia. Un índice en (a) a menudo es innecesario si ya tiene uno en (a, b).

Verifique las estadísticas de uso periódicamente y elimine los índices que no utiliza. Y mantenga las estadísticas actualizadas con ANALYZE o el equivalente de su base de datos, porque el optimizador depende de ellos para elegir un buen plan. A veces, la parte lenta es la contienda más que la consulta. Las transacciones de larga duración que mantienen bloqueos pueden hacer que una consulta rápida parezca lenta.

Errores comunes

• Optimizar sin medir. Muchas suposiciones seguras resultan erróneas.
• Pruebas con datos pequeños. Los planes y tiempos cambian dramáticamente a medida que las tablas crecen.
• Confiar en un consejo para otra base de datos. Es posible que los consejos para un motor no se apliquen a otro.
• Agregar índices a ciegas. Cada uno ralentiza la escritura.
• Ignorando el efecto de la primera ejecución. Los cachés hacen que la segunda ejecución sea más rápida, así que ejecútala varias veces.

Conclusión

La mayoría de las consultas lentas tienen causas comunes: falta un índice, una función en una columna o se están recuperando demasiados datos. Realice su consulta real más lenta esta semana, ejecute EXPLAIN en ella y busque un escaneo completo en una tabla grande. Arregle una cosa, mida nuevamente y tome notas de lo que cambió.

Preguntas frecuentes

sigue aprendiendo