Escaneos secuenciales frente a escaneos mediante índices
Aprenda cuándo un escaneo secuencial es suficiente, cuándo se necesita un escaneo mediante índices y cómo decide el planificador.
Escaneos secuenciales frente a escaneos mediante índices es una lección gratuita de SQL Academy en CoddyKit. Esta es la lección 2 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de SQL Academy, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de SQL Academy incluye 4 lecciones en total.
Dos formas de buscar filas
La base de datos tiene dos estrategias básicas para leer filas:
- Sequential Scan — lee todas las páginas de la tabla
- Index Scan — recorre un índice y obtiene las filas coincidentes
Cuándo conviene Sequential Scan
Si necesita de todos modos la mayor parte de la tabla, recorrerla es más barato que leer el índice Y obtener cada fila coincidente. Como regla general: si supera aproximadamente el 10–20 % de las filas, gana el seq scan.
Cuándo gana Index Scan
En consultas selectivas, que afectan a una pequeña fracción de las filas, el índice resulta rentable:
EXPLAIN SELECT * FROM users WHERE id = 42;
-- Index Scan using users_pkey (cost=0.43..8.45 rows=1)
EXPLAIN SELECT * FROM users WHERE active;
-- Seq Scan on users (cost=0.00..15000.00 rows=950000)
-- (because most users are active)Index Scan frente a Index-Only Scan
A veces el índice contiene por sí solo todas las columnas que necesita, por lo que no hace falta acceder a la tabla. Esto se denomina Index-Only Scan:
CREATE INDEX users_email_id_idx ON users(id) INCLUDE (email);
EXPLAIN SELECT email FROM users WHERE id = 42;
-- Index Only Scan using users_email_id_idxBitmap Index Scan
Para una selectividad intermedia, PostgreSQL puede crear un mapa de bits de las filas coincidentes y después obtenerlas en orden físico, lo que es más rápido que la E/S aleatoria:
EXPLAIN SELECT * FROM orders WHERE status = 'pending';
-- Bitmap Heap Scan on orders
-- Recheck Cond: (status = 'pending')
-- -> Bitmap Index Scan on orders_status_idxPor qué el planificador elige Seq Scan
Motivos frecuentes:
- No hay ningún índice en la columna filtrada
- No se puede usar el índice — hay una función sobre la columna, cláusulas OR o incompatibilidades de tipos
- El número de filas esperado es demasiado alto para que el índice resulte rentable
- Las estadísticas están desactualizadas y el planificador calcula mal la selectividad
Forzar el uso de índices (con cuidado)
No puede indicar directamente sugerencias a PostgreSQL. En su lugar:
- Ejecute ANALYZE para actualizar las estadísticas
- Añada el índice adecuado
- Establezca parámetros de sesión:
SET enable_seqscan = off;para diagnosticar, no para producción
Predicados indexables
Para que un índice sea útil, la cláusula WHERE debe ser «sargable»: debe comparar directamente la columna indexada:
-- GOOD:
WHERE created_at >= '2024-01-01'
-- BAD (function on the column):
WHERE date_trunc('day', created_at) = '2024-01-01'
-- BAD (cast):
WHERE created_at::DATE = '2024-01-01'
-- FIX: add a functional index, or rewrite with range.Orden de un índice compuesto
Un índice sobre (a, b) ayuda a las consultas que usan solo a y a las que usan a AND b, pero no a las que usan solo b.
El tamaño del índice importa
Un índice B-tree estrecho con claves de uso frecuente puede permanecer completamente en memoria; uno ancho quizá no. Los índices más pequeños son más rápidos.
Verifique el plan
Después de añadir un índice, ejecute EXPLAIN ANALYZE para confirmar que el planificador realmente lo usa. Si no es así, investigue el motivo.
Resumen
La elección entre un recorrido secuencial y uno mediante índice depende de la selectividad.
- Filtro selectivo → index scan
- La mayor parte de la tabla → seq scan
- Bitmap scan para los casos intermedios
- Preste atención a la sargabilidad
Comprobación rápida
¿Por qué podría PostgreSQL elegir un recorrido secuencial en lugar de un índice existente?
Preguntas frecuentes
¿La lección «Escaneos secuenciales frente a escaneos mediante índices» es gratis?
Sí — el texto completo de «Escaneos secuenciales frente a escaneos mediante índices» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de SQL Academy, actualiza a CoddyKit PRO. El curso de SQL Academy incluye 4 lecciones en total.
¿Qué aprenderé en «Escaneos secuenciales frente a escaneos mediante índices»?
Aprenda cuándo un escaneo secuencial es suficiente, cuándo se necesita un escaneo mediante índices y cómo decide el planificador. Practicas SQL Academy con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.
¿Necesito experiencia previa para empezar SQL Academy?
No se requiere experiencia previa. SQL Academy en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 2 de 4.
¿Cuánto tiempo toma la lección «Escaneos secuenciales frente a escaneos mediante índices»?
La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.
¿Puedo escribir y ejecutar código en esta lección de SQL Academy?
Sí. Cada lección de SQL Academy incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.
Todas las lecciones de este curso
- Interpretación de EXPLAIN y EXPLAIN ANALYZE
- Escaneos secuenciales frente a escaneos mediante índices
- Hash Join frente a Merge Join y Nested Loop
- Identificación y corrección de consultas lentas