Cuándo perjudican los índices: escrituras y selectividad
La amplificación de escritura y por qué un índice sobre una columna con baja selectividad no sirve.
Cuándo perjudican los índices: escrituras y selectividad es una lección gratuita de SQL Interview Prep en CoddyKit. Esta es la lección 4 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 Interview Prep, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de SQL Interview Prep incluye 4 lecciones en total.
La pregunta que hay detrás de la pregunta
Después de tres lecciones sobre por qué los índices ayudan, los entrevistadores cambian el enfoque: «¿Por qué no crear un índice para cada columna?» Un buen candidato explica que los índices tienen costes reales en las escrituras y en la caché y el almacenamiento, y que el planificador puede no utilizar algunos índices en absoluto.
Esta lección trata las dos razones principales por las que un índice puede perjudicar el rendimiento: la amplificación de escritura y la baja selectividad.
Cada índice ralentiza las escrituras
Un índice debe mantenerse sincronizado con la tabla. Cada INSERT, cada DELETE y cada UPDATE de una columna indexada también debe actualizar la estructura del índice. Esto es la amplificación de escritura: un cambio en una fila se convierte en una escritura en la tabla más una escritura por cada índice afectado.
Una tabla con ocho índices soporta aproximadamente nueve veces el trabajo de escritura de una tabla sin índices. En tablas con muchas escrituras o de alto rendimiento, es un coste considerable.
Ejemplo resuelto: el coste de escritura
Imagine una tabla de eventos que recibe miles de filas por segundo. Cada índice adicional hace que cada inserción requiera más trabajo, provoque divisiones de páginas de índice, actualice las hojas y compita por la caché.
Para una tabla de solo inserción y dominada por las escrituras, la respuesta adecuada suele ser tener pocos índices o ninguno además de la clave principal, y realizar las lecturas intensivas en una réplica o en un almacén de datos.
-- Each of these indexes adds cost to EVERY insert below
CREATE INDEX ix_events_user ON events (user_id);
CREATE INDEX ix_events_type ON events (event_type);
CREATE INDEX ix_events_ts ON events (created_at);
INSERT INTO events (user_id, event_type, created_at)
VALUES (42, 'click', now()); -- now updates table + 3 indexesQué significa la selectividad
La selectividad indica en qué medida una columna distingue unas filas de otras: es la fracción de filas que coincide con un valor típico. Una selectividad alta significa pocas filas por valor, como ocurre con un correo electrónico o un UUID. Una selectividad baja significa muchas filas por valor, como ocurre con un booleano o un estado con tres opciones.
Los índices resultan útiles en columnas de alta selectividad, donde una búsqueda descarta casi todas las filas. En columnas de baja selectividad, a menudo no resultan útiles.
Por qué un índice de baja selectividad no sirve
Suponga que is_active es verdadero para el 90 % de los usuarios. Una búsqueda mediante el índice devolvería el 90 % de la tabla y, para tantas filas, el motor tendría que acceder al heap una vez por fila, lo que sería más lento que recorrer la tabla secuencialmente en una sola pasada.
Por eso el planificador ignora correctamente el índice y realiza un escaneo secuencial. El índice solo supone una sobrecarga de escritura y almacenamiento, sin aportar ningún beneficio en las lecturas.
-- 90% of rows match: the planner will likely skip this index
CREATE INDEX ix_users_active ON users (is_active);
SELECT * FROM users WHERE is_active = true;El umbral aproximado
Una regla práctica que puede mencionar es la siguiente: cuando un predicado devuelve más de aproximadamente el 5–20 % de las filas de una tabla, un escaneo secuencial suele superar a un escaneo mediante índice, porque los accesos aleatorios al heap cuestan más que leer las páginas secuencialmente.
El punto exacto de cambio depende del tamaño de las filas, la caché y la velocidad del almacenamiento; por eso el planificador utiliza estadísticas, no una cifra fija, para decidir.
Los índices parciales al rescate
Si solo consulta los valores poco frecuentes de una columna sesgada, un índice parcial (Postgres) indexa únicamente esas filas: es pequeño, selectivo y barato de mantener.
Si el 1 % de los pedidos está pending y esos son los que consulta constantemente, indexe solo esos pedidos. El índice se mantiene pequeño y el planificador lo utilizará con facilidad.
-- Index only the rare, frequently-queried rows
CREATE INDEX ix_orders_pending
ON orders (created_at)
WHERE status = 'pending';Las estadísticas obsoletas confunden al planificador
El optimizador decide entre un índice y un escaneo a partir de las estadísticas de las columnas. Si están desactualizadas, después de una carga masiva o de una actualización importante, puede calcular mal la selectividad y elegir el plan equivocado.
Cuando un entrevistador dice «el índice existe, pero no se utiliza», una respuesta excelente incluye actualizar las estadísticas con ANALYZE antes de culpar al índice.
ANALYZE orders; -- refresh planner statisticsOtras formas en que los índices perjudican
Complete la respuesta con costes menos conocidos:
- Almacenamiento y caché: los índices ocupan espacio en disco y compiten por la memoria, expulsando páginas de datos útiles.
- Índices redundantes o solapados: se mantienen, pero nunca se eligen.
- Bloat: con muchas actualizaciones, los B-Trees se fragmentan y necesitan
REINDEX. - Confusión del optimizador: demasiados índices similares hacen que la planificación sea más lenta y menos predecible.
Cómo encontrar índices sin uso
Para justificar una limpieza en un entorno real, mencione que Postgres registra el uso de los índices. Los índices con idx_scan = 0 son candidatos a eliminar: consumen recursos de escritura y espacio, pero nunca atienden una lectura.
SELECT relname AS table_name, indexrelname AS index_name, idx_scan
FROM pg_stat_user_indexes
WHERE idx_scan = 0
ORDER BY relname;Cómo expresarlo en la entrevista
Un resumen completo y equilibrado:
«Los índices generan amplificación de escritura: cada inserción, actualización o eliminación debe mantenerlos, y además ejercen presión sobre el almacenamiento y la caché. Solo compensan en predicados de alta selectividad; en una columna que coincide con la mayoría de las filas, el planificador prefiere correctamente un escaneo secuencial, por lo que el índice es pura sobrecarga. Para columnas sesgadas, recurro a un índice parcial, mantengo actualizadas las estadísticas con ANALYZE y elimino los índices sin uso.»
Comprobación rápida
Decida qué índice tiene menos probabilidades de compensar su coste.
Repaso: cuándo perjudican los índices
Ideas clave:
- Cada índice añade amplificación de escritura, además de costes de almacenamiento y caché.
- Los índices ayudan en columnas de alta selectividad; en las de baja selectividad, el planificador prefiere un escaneo secuencial.
- Por encima de aproximadamente el 5–20 % de filas coincidentes, normalmente gana el escaneo.
- Utilice un índice parcial para columnas sesgadas que solo consulta con sus valores poco frecuentes.
- Mantenga las estadísticas actualizadas con
ANALYZEy elimine los índices sin uso (idx_scan = 0).
Con esto termina el curso de estrategia de indexación: créelos donde compensen su coste y demuéstrelo con el plan.
Preguntas frecuentes
¿La lección «Cuándo perjudican los índices: escrituras y selectividad» es gratis?
Sí — el texto completo de «Cuándo perjudican los índices: escrituras y selectividad» 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 Interview Prep, actualiza a CoddyKit PRO. El curso de SQL Interview Prep incluye 4 lecciones en total.
¿Qué aprenderé en «Cuándo perjudican los índices: escrituras y selectividad»?
La amplificación de escritura y por qué un índice sobre una columna con baja selectividad no sirve. Practicas SQL 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 SQL Interview Prep?
No se requiere experiencia previa. SQL 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 4 de 4.
¿Cuánto tiempo toma la lección «Cuándo perjudican los índices: escrituras y selectividad»?
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 Interview Prep?
Sí. Cada lección de SQL 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
- Índices B-Tree y cómo ayudan
- Orden de las columnas en índices compuestos
- Índices de cobertura y escaneos Index-Only
- Cuándo perjudican los índices: escrituras y selectividad