Quiz de Indexación de Bases de Datos

Quiz de Indexación de Bases de Datos

Pon a prueba tus conocimientos sobre árboles B, estrategias de índices y optimización de consultas.

1. 1. ¿Qué es un índice de base de datos?

   • Una copia de seguridad de toda la tabla almacenada en un disco independiente
   • Una estructura de datos independiente que mapea los valores de las columnas con las ubicaciones de las filas, acelerando la recuperación de datos
   • Una restricción que impone la unicidad de las filas en una tabla
   • Un registro de transacciones que registra cada INSERT, UPDATE y DELETE

2. 2. ¿Cuál de las siguientes opciones describe mejor el trade-off entre lectura y escritura al agregar un índice?

   • Los índices aceleran tanto las lecturas como las escrituras por igual
   • Los índices ralentizan las lecturas porque el optimizador debe verificar primero el índice
   • Los índices aceleran las lecturas, pero agregan sobrecarga a las operaciones INSERT, UPDATE y DELETE
   • Los índices solo afectan el rendimiento de DELETE, no de SELECT

3. 3. ¿Qué distingue a un índice primario de un índice secundario?

   • Un índice primario siempre es un índice hash; los índices secundarios siempre son árboles B
   • Un índice primario se construye sobre la clave primaria y habitualmente determina el orden físico de las filas; los índices secundarios se crean sobre otras columnas
   • Un índice primario solo se puede definir al crear la tabla; los índices secundarios se pueden agregar en cualquier momento
   • No hay diferencia práctica: los términos son intercambiables

4. 4. ¿Qué es un escaneo completo de tabla (full table scan) y cuándo lo utiliza la base de datos?

   • La lectura secuencial de cada fila de la tabla; se utiliza cuando no existe un índice adecuado o cuando el optimizador estima que es más económico que un escaneo de índice
   • La lectura únicamente de la primera y última fila de una tabla para estimar su tamaño
   • Una operación especial que reconstruye todos los índices de la tabla
   • Un escaneo que solo lee las filas que coinciden con una cláusula WHERE

5. 5. Dada la consulta `SELECT * FROM orders WHERE customer_id = 42`, ¿qué condición permite a la base de datos usar un índice en `customer_id`?

   • La tabla debe tener menos de 1.000 filas
   • Debe existir un índice en la columna `customer_id`
   • `customer_id` debe ser la primera columna definida en la tabla
   • La consulta debe incluir `LIMIT 1`

6. 6. ¿Qué garantiza un índice UNIQUE?

   • Que la columna indexada nunca sea NULL
   • Que no existan dos filas con el mismo valor en la(s) columna(s) indexada(s)
   • Que el índice se almacene en un tablespace separado de los datos de la tabla
   • Que las consultas SELECT sobre esa columna siempre devuelvan resultados ordenados

7. 7. En PostgreSQL, ¿qué muestra el comando `EXPLAIN`?

   • La versión estándar SQL de tu consulta después de la reescritura automática
   • El plan de ejecución que el optimizador prevé utilizar, incluidos los tipos de nodos, costos estimados y recuentos de filas
   • Una lista de todos los índices en las tablas a las que hace referencia la consulta
   • El tiempo real de ejecución que tardó la consulta

8. 8. ¿Cuál es la diferencia clave entre un índice clusterizado (agrupado) y uno no clusterizado?

   • Un índice clusterizado almacena los datos reales de las filas en el orden del índice; un índice no clusterizado solo almacena punteros a las filas de datos
   • Un índice clusterizado solo puede crearse en una sola columna; los índices no clusterizados admiten múltiples columnas
   • Los índices no clusterizados son más rápidos para todo tipo de consultas
   • Los índices clusterizados requieren más espacio en disco que los índices no clusterizados

9. 9. ¿Por qué los índices en columnas de baja cardinalidad (por ejemplo, un booleano `is_active`) suelen ser ineficaces?

   • La base de datos no puede construir índices en árbol B en columnas booleanas
   • Cuando una columna tiene muy pocos valores distintos, el escaneo por índice puede acceder a gran parte de la tabla, haciendo más económico un escaneo secuencial
   • El motor de base de datos elimina automáticamente los índices de baja cardinalidad
   • Los índices en booleanos requieren un motor de almacenamiento especial no disponible en PostgreSQL estándar

10. 10. ¿Qué ocurre con un índice cuando se actualiza la columna indexada de una fila?

    • Nada: los índices se actualizan únicamente durante el siguiente VACUUM
    • La entrada antigua del índice se elimina y se inserta una nueva para reflejar el valor actualizado
    • Todo el índice se reconstruye desde cero después de cada UPDATE
    • La entrada del índice se marca como inválida hasta que se ejecute el siguiente SELECT

11. 11. Al recorrer un índice en árbol B para encontrar el valor de una clave, ¿cuál es la complejidad temporal de la búsqueda?

    • O(n): lineal respecto al número de filas
    • O(log n): logarítmica respecto al número de filas
    • O(1): tiempo constante sin importar el tamaño de la tabla
    • O(n²): cuadrática respecto al número de filas

12. 12. ¿Qué afirmación contrasta correctamente un índice hash con un índice en árbol B?

    • Los índices hash admiten consultas por rango (>, <, BETWEEN); los árboles B no
    • Los índices hash ofrecen búsquedas por igualdad en O(1), pero no admiten consultas por rango ni ORDER BY; los árboles B admiten todas ellas
    • Los índices hash almacenan datos en orden secuencial, lo que hace muy rápidos los escaneos por rango
    • Los índices hash y en árbol B tienen características idénticas de rendimiento; la elección es meramente cosmética

13. 13. Dado un índice compuesto en `(last_name, first_name)`, ¿cuál cláusula WHERE puede utilizar el índice de manera eficiente?

    • `WHERE first_name = 'Alice'` (omitiendo `last_name`)
    • `WHERE last_name = 'Smith'`
    • `WHERE first_name = 'Alice' AND last_name = 'Smith'`: solo cuando aparecen ambas columnas
    • Ninguna columna puede usar el índice a menos que la consulta incluya todas las columnas indexadas

14. 14. ¿Qué es un índice de cobertura (covering index)?

    • Un índice que abarca todas las columnas de la tabla
    • Un índice que contiene todas las columnas requeridas para resolver una consulta, permitiendo al motor devolver resultados únicamente desde el índice sin consultar la heap de la tabla
    • Un índice que se expande automáticamente para cubrir nuevas columnas a medida que se agregan a la tabla
    • Un índice que cubre valores NULL que los índices estándar normalmente omitirían

15. 15. ¿Qué es la selectividad de un índice y por qué es importante para el optimizador de consultas?

    • El número de páginas que ocupa el índice en disco; mayor cantidad de páginas implica escaneos más rápidos
    • La proporción de valores distintos respecto al total de filas; una alta selectividad indica pocas filas por valor de clave, haciendo el índice más útil para búsquedas
    • Indica si el índice fue creado o no en una columna de clave primaria
    • El porcentaje de consultas en la carga de trabajo que hacen referencia a la columna indexada

16. 16. ¿Qué es un índice parcial en PostgreSQL?

    • Un índice construido únicamente sobre los primeros N bytes de una columna de texto
    • Un índice que incluye solo las filas que cumplen un predicado WHERE, reduciendo su tamaño y costo de mantenimiento
    • Un índice que cubre solo la mitad de una clave compuesta
    • Un índice creado automáticamente por el optimizador para la ejecución de una sola consulta

17. 17. ¿Qué es un índice basado en funciones (o de expresiones)?

    • Un índice almacenado como procedimiento almacenado que se regenera cada noche
    • Un índice construido sobre el resultado de una expresión o función aplicada a una o más columnas, permitiendo escaneos indexados sobre predicados calculados
    • Un índice que activa una función personalizada cada vez que se inserta una fila
    • Un índice cuyos valores de clave se encriptan mediante una función hash por seguridad

18. 18. ¿Qué es la hinchazón de índices (index bloat) y cómo ayuda VACUUM en PostgreSQL?

    • La hinchazón ocurre cuando un índice tiene demasiadas columnas; VACUUM elimina las columnas sobrantes automáticamente
    • La hinchazón es la acumulación de referencias a tuplas muertas en las páginas del índice debido a UPDATEs y DELETEs; VACUUM recupera esas páginas y las marca como reutilizables
    • La hinchazón indica que el archivo del índice supera el tamaño de la tabla; VACUUM comprime ambos al mismo tamaño
    • La hinchazón es producida por demasiadas lecturas concurrentes; VACUUM reinicia los contadores de lectura

19. 19. ¿Por qué el optimizador de consultas de PostgreSQL podría ignorar un índice aunque exista en la columna filtrada?

    • PostgreSQL nunca ignora un índice una vez creado: siempre se utiliza
    • El modelo de costos del optimizador estima que un escaneo secuencial es más económico, comúnmente porque el filtro coincide con una gran proporción de filas o las estadísticas están desactualizadas
    • El índice solo puede usarse si la consulta incluye una cláusula ORDER BY sobre la columna indexada
    • Los índices solo se utilizan en operaciones JOIN, nunca para filtros de cláusula WHERE

20. 20. Dado un índice en árbol B en una columna `name`, ¿qué patrón LIKE puede utilizar el índice?

    • `WHERE name LIKE '%smith'` (comodín como sufijo)
    • `WHERE name LIKE '%smith%'` (comodines en ambos extremos)
    • `WHERE name LIKE 'smith%'` (comodín como prefijo)
    • Ninguno: LIKE nunca utiliza un índice en árbol B

21. 21. ¿Qué tipo de índice de PostgreSQL está diseñado para tipos de datos geométricos y espaciales como puntos, cajas y polígonos?

    • GIN (Generalized Inverted Index)
    • BRIN (Block Range INdex)
    • GiST (Generalized Search Tree)
    • SPGIST (Space-Partitioned GiST)

22. 22. ¿Para qué tipo de columna resulta más apropiado un índice GIN (Generalized Inverted Index)?

    • Una clave primaria entera de valor único
    • Una columna con valores compuestos como arrays, JSONB o documentos de búsqueda de texto completo `tsvector`
    • Una columna de marca de tiempo creciente monótonamente en una tabla append-only
    • Una columna booleana de baja cardinalidad

23. 23. ¿Qué es un índice BRIN y para qué característica de tabla es más adecuado?

    • Un índice de rango de bloques que almacena valores mínimos/máximos por conjunto de páginas; ideal para tablas grandes con columnas correlacionadas físicamente como `created_at` en tablas append-only
    • Un índice de rango balanceado que sustituye a los árboles B en todas las columnas numéricas
    • Un índice de mapa de bits para acelerar escaneos bitmap de heap sobre datos aleatorios
    • Un índice de rango binario que solo opera con claves primarias UUID

24. 24. ¿Qué es la 'amplificación de escritura' (write amplification) en el contexto de índices LSM-tree (Log-Structured Merge-tree)?

    • Cada escritura lógica se escribe físicamente múltiples veces en diferentes niveles del árbol LSM durante la compactación
    • La base de datos escribe una copia redundante de cada fila en el registro de transacciones
    • La sobrecarga generada al actualizar los nodos padre de un árbol B tras la división de una hoja (leaf split)
    • La latencia adicional producida al vaciar el write-ahead log al disco

25. 25. ¿Cuál es el propósito de `CREATE INDEX CONCURRENTLY` en PostgreSQL?

    • Construye el índice en múltiples núcleos de CPU de forma simultánea para reducir el tiempo de creación
    • Construye el índice sin adquirir un bloqueo exclusivo sobre la tabla, permitiendo lecturas y escrituras concurrentes durante la creación a costa de un tiempo total mayor
    • Crea el índice en una réplica antes de promoverla a nodo principal, evitando períodos de inactividad
    • Pospone la validación del índice hasta después de un COMMIT, incrementando el throughput transaccional

26. 26. ¿Qué es un 'índice invisible' (soportado en MySQL 8+ y Oracle) y cuál es su caso de uso principal?

    • Un índice cifrado en reposo para impedir que usuarios no autorizados lean su contenido
    • Un índice mantenido por el motor pero oculto para el optimizador de consultas, empleado para probar de forma segura el impacto de eliminar un índice antes de borrarlo definitivamente
    • Un índice almacenado únicamente en memoria que nunca se persiste en disco
    • Un índice en tablas de catálogo del sistema que no se expone en las vistas de information_schema

27. 27. ¿De qué forma contribuye el modelo MVCC (Multi-Version Concurrency Control) de PostgreSQL al fenómeno de hinchazón de índices (index bloat) con el tiempo?

    • El modelo MVCC comprime versiones antiguas de filas, fragmentando los índices progresivamente
    • Cada UPDATE genera una nueva versión de tupla en la heap conservando la anterior; las entradas antigua y nueva coexisten en el índice hasta que VACUUM libera las tuplas muertas
    • MVCC obliga al índice a almacenar el identificador de transacción junto a cada clave, duplicando su tamaño
    • MVCC no produce impacto en los índices: únicamente las páginas de heap acumulan tuplas muertas

28. 28. ¿Cuándo elige el optimizador de PostgreSQL un Bitmap Index Scan en lugar de un Index Scan convencional?

    • Cuando la consulta devuelve únicamente una sola fila
    • Cuando se deben combinar múltiples índices (AND/OR) o cuando la cantidad estimada de filas es moderada, permitiendo leer las páginas de la heap en orden físico en lugar de hacer lecturas aleatorias repetidas
    • Cuando la tabla carece de páginas de heap: los datos residen en el propio índice
    • El Bitmap Index Scan siempre es más rápido y se prefiere en cualquier caso frente a un Index Scan normal

29. 29. En una tabla particionada, ¿cuál es una consideración fundamental al crear índices para asegurar que beneficien a todas las particiones?

    • Los índices deben crearse únicamente sobre la clave de partición; no se pueden indexar otras columnas
    • Crear un índice en la tabla particionada principal en PostgreSQL 11+ propaga automáticamente el índice a todas las particiones actuales y futuras
    • Cada partición requiere la creación manual de un índice con nombre único; no existe propagación automática
    • Las tablas particionadas no admiten índices en árbol B; únicamente se permiten índices BRIN

30. 30. ¿Qué vista de sistema de PostgreSQL consultarías para obtener el recuento de escaneos de índice, escaneos secuenciales y tuplas recuperadas de índices de usuario?

    • `pg_indexes`
    • `information_schema.table_constraints`
    • `pg_stat_user_indexes`
    • `pg_index`