Ejecuta explain analyze para obtener el plan real con conteos y tiempos reales, luego busca el nodo que consume más tiempo y compara filas estimadas con filas reales. Una diferencia grande significa estadísticas malas, así que el planificador eligió mal el join o el escaneo. Busca escaneos secuenciales sobre tablas grandes, nested loops provocados por una subestimación y ordenaciones que se van a disco. Arréglalo con un índice, estadísticas actualizadas o un predicado reescrito que el índice pueda usar.
Por qué lo preguntan los entrevistadores
Cualquier desarrollador de backend sabe añadir un índice; el entrevistador comprueba si diagnosticas antes de hacerlo. Leer filas reales frente a estimadas, detectar un predicado que impide usar el índice y saber que un escaneo secuencial sobre una tabla pequeña está bien son señales de trabajo real con bases de datos. También abre la puerta a si miras toda la carga de trabajo, porque una consulta rara vez se vuelve lenta ella sola.
Cómo estructurar tu respuesta
- Consigue el plan real con explain analyze, no solo explain.
- Encuentra el nodo dominante y compara filas estimadas con reales.
- Asocia los patrones habituales con sus causas.
- Verifica el arreglo midiendo el plan otra vez, no por intuición.
Ejemplo de respuesta
Empiezo con explain analyze y buffers para tener tiempos y conteos reales, idealmente contra datos de tamaño de producción, porque un plan sobre un conjunto pequeño no me dice nada. Después busco el nodo que se lleva la mayor parte del tiempo y comparo su estimación con lo real. Si estimó una fila y salieron cincuenta mil, el planificador eligió un nested loop que ahora es un desastre, y la causa suele ser estadísticas obsoletas o un predicado correlacionado que el planificador no sabe modelar. Luego busco a los sospechosos habituales: un escaneo secuencial sobre una tabla grande, un filtro que podría ser condición de índice, una ordenación que se va a disco, o una función envolviendo la columna que deja el índice inutilizable. Ese último fue mi caso más reciente, una llamada a lower sobre una columna de email que ignoraba el índice; un índice funcional sobre lower de email lo bajó de unos 900 milisegundos a dos. Después vuelvo a sacar el plan para confirmar que la forma ha cambiado, porque una ejecución rápida con la caché caliente no demuestra nada.
¿Tienes esta entrevista a la vuelta de la esquina? GhostPilot escucha tu llamada en vivo, detecta la pregunta en cuanto la hacen y pone una respuesta estructurada en tu pantalla en tiempo real. Pruébalo en tu próxima entrevista de práctica, o coge un Session Pass de $29, sin suscripción, para la de verdad.
Mira cómo funcionaPreguntas de seguimiento que puedes esperar
- ¿Qué hace que un predicado no pueda usar un índice?
- ¿Cómo distingues un problema de estadísticas de un índice que falta?
- ¿Cuándo es un escaneo secuencial el plan correcto?
Más preguntas para Desarrollador backend
Tu entrevistador hará su propia versión de esta. Pega la descripción real del puesto en el Question Predictor gratuito y obtén las 20 preguntas que ese puesto tiene más probabilidades de hacerte, con lo que cada una busca en realidad.
Predecir mis preguntas