0Pricing
Coding Interview Prep · Lección

Índices de cobertura y escaneos Index-Only

Incluir columnas para que una consulta nunca tenga que acceder al heap de la tabla.

Índices de cobertura y escaneos Index-Only es una lección gratuita de Coding Interview Prep en CoddyKit. Esta es la lección 3 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 Coding Interview Prep, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de Coding Interview Prep incluye 4 lecciones en total.

Recordatorio del acceso al heap

Antes aprendió que un B-Tree normal almacena solo las columnas indexadas y un puntero a la fila, de modo que, después de que el índice encuentra las coincidencias, el motor todavía debe ir a la tabla para leer las demás columnas. Ese salto es el acceso al heap y es el coste que un índice de cobertura está diseñado para eliminar.

Los entrevistadores preguntan por los índices de cobertura para comprobar si entiende por qué un índice puede responder por completo a una consulta sin acceder a la tabla.

Qué significa «de cobertura»

Un índice cubre una consulta cuando todas las columnas que esta necesita, en SELECT, WHERE, ORDER BY y GROUP BY, están presentes en el propio índice.

Cuando se cumple esta condición, el motor solo lee el índice y nunca visita la tabla. PostgreSQL denomina esto Index-Only Scan; SQL Server y otros sistemas lo llaman índice de cobertura. La ventaja es que se leen menos páginas y las consultas son más rápidas.

Ejemplo resuelto: una consulta cubierta

Suponga que una consulta solo necesita customer_id y order_date. Un índice compuesto exactamente sobre esas columnas contiene todo lo que solicita la consulta, por lo que esta puede resolverse únicamente desde el índice.

CREATE INDEX idx_orders_cust_date
  ON orders (customer_id, order_date);

-- Covered: both selected columns are in the index
SELECT customer_id, order_date
FROM orders
WHERE customer_id = 42;

Una columna adicional elimina la cobertura

Si añade una columna que el índice no contiene, se pierde la cobertura y el motor debe acceder al heap para obtenerla.

Aquí total no está en el índice, por lo que, aunque customer_id dirige la búsqueda, cada fila coincidente provoca un acceso al heap para leer total.

-- NOT covered: total is not in the index, forces heap fetches
SELECT customer_id, order_date, total
FROM orders
WHERE customer_id = 42;

La cláusula INCLUDE

Podría añadir total como cuarta columna clave, pero, si nunca se filtra ni se ordena por ella, eso desperdicia espacio en el orden de clasificación del árbol. La opción más adecuada es INCLUDE (compatible con PostgreSQL y SQL Server): almacena las columnas adicionales solo en las hojas del índice, como datos adicionales y no como parte de la clave de ordenación.

Ahora la consulta queda cubierta sin agrandar la parte consultable del índice.

CREATE INDEX idx_orders_cust_date_inc
  ON orders (customer_id, order_date)
  INCLUDE (total);

-- Now covered: total is carried in the leaf
SELECT customer_id, order_date, total
FROM orders
WHERE customer_id = 42;

Columnas clave frente a columnas incluidas

Una distinción precisa que impresiona a los entrevistadores:

  • Las columnas clave definen el orden de clasificación y pueden utilizarse para búsquedas y recorridos por rangos. Siguen la regla del prefijo más a la izquierda.
  • Las columnas incluidas solo se almacenan en las hojas como datos adicionales; no se pueden buscar, pero permiten que el índice cubra más consultas.

Regla práctica: las columnas por las que filtra u ordena van en la clave; las columnas que solo devuelve van en INCLUDE.

MySQL/InnoDB: el matiz del índice agrupado

Demuestre que conoce las diferencias entre dialectos. Las tablas de InnoDB (MySQL) están agrupadas por la clave principal: los índices secundarios incluyen implícitamente las columnas de la clave principal. Por tanto, un índice secundario cubre automáticamente cualquier consulta que seleccione solo las columnas indexadas y las columnas de la clave principal; no hace falta ninguna cláusula INCLUDE (MySQL no tiene INCLUDE).

El concepto de cobertura es universal; la sintaxis y las columnas que se incluyen automáticamente varían según el motor.

Cómo verificar un Index-Only Scan

Demuestre la cobertura con EXPLAIN. En PostgreSQL, el nodo del plan muestra Index Only Scan en lugar de Index Scan. Busque Heap Fetches: 0 en EXPLAIN (ANALYZE); esa es la señal definitiva de que no se accedió a la tabla.

Si esperaba un Index-Only Scan, pero ve Index Scan con accesos al heap, falta una columna seleccionada en el índice.

EXPLAIN (ANALYZE)
SELECT customer_id, order_date, total
FROM orders
WHERE customer_id = 42;
-- Look for: Index Only Scan ... Heap Fetches: 0

La salvedad del mapa de visibilidad de Postgres

Un detalle sutil de Postgres que merece un punto extra: un Index-Only Scan todavía puede acceder al heap si una página no está marcada como totalmente visible en el mapa de visibilidad. Después de muchas actualizaciones, ejecute VACUUM para que el mapa de visibilidad esté actualizado; de lo contrario, aumentará Heap Fetches y se reducirá la ventaja del acceso «solo mediante índice».

-- Keeps the visibility map fresh so index-only scans stay heap-free
VACUUM ANALYZE orders;

Cuándo NO crear un índice de cobertura amplio

Los índices de cobertura no son gratuitos. Incluir muchas columnas en INCLUDE hace que el índice sea grande, consuma caché y ralentice las escrituras (cada escritura relevante actualiza el índice). Aspectos que debe mencionar:

  • Son excelentes para consultas de lectura acotadas y muy frecuentes.
  • Son una mala opción para almacenar todas las columnas «por si acaso».

Cubra la consulta importante, no la fila completa.

Cómo expresarlo en la entrevista

Un resumen claro:

«Un índice de cobertura contiene todas las columnas que utiliza una consulta, por lo que el motor la resuelve únicamente desde el índice mediante un Index-Only Scan y omite el acceso al heap. Coloco las columnas consultadas en la clave y las columnas que solo se devuelven en INCLUDE, verifico con EXPLAIN ANALYZE que Heap Fetches sea cero y mantengo el índice estrecho para proteger el rendimiento de escritura.»

Comprobación rápida

Razone sobre la cobertura y el lugar adecuado para cada columna.

Repaso: índices de cobertura

Ideas clave:

  • Un índice cubre una consulta cuando contiene todas las columnas que esta necesita, lo que permite un Index-Only Scan sin acceso al heap.
  • Las columnas clave dirigen las búsquedas y siguen la regla del prefijo más a la izquierda; las columnas de INCLUDE son datos adicionales que solo están en las hojas y sirven para la cobertura.
  • Los índices secundarios de InnoDB incluyen implícitamente la clave principal.
  • Verifique con EXPLAIN (ANALYZE) y observe Heap Fetches; en Postgres mantenga VACUUM actualizado.
  • Mantenga los índices de cobertura estrechos para proteger el rendimiento de escritura.

A continuación: la otra cara, cuándo los índices realmente perjudican el rendimiento.

Preguntas frecuentes

¿La lección «Índices de cobertura y escaneos Index-Only» es gratis?

Sí — el texto completo de «Índices de cobertura y escaneos Index-Only» 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 Coding Interview Prep, actualiza a CoddyKit PRO. El curso de Coding Interview Prep incluye 4 lecciones en total.

¿Qué aprenderé en «Índices de cobertura y escaneos Index-Only»?

Incluir columnas para que una consulta nunca tenga que acceder al heap de la tabla. Practicas Coding Interview Prep 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 Coding Interview Prep?

No se requiere experiencia previa. Coding Interview Prep 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 3 de 4.

¿Cuánto tiempo toma la lección «Índices de cobertura y escaneos Index-Only»?

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 Coding Interview Prep?

Sí. Cada lección de Coding Interview Prep 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

  1. Índices B-Tree y cómo ayudan
  2. Orden de las columnas en índices compuestos
  3. Índices de cobertura y escaneos Index-Only
  4. Cuándo perjudican los índices: escrituras y selectividad
← Volver a Coding Interview Prep