Comparativa independiente · sin rankings de pago
Inicio / Blog / Técnico / Falta el índice MySQL: reconoce la consulta que hace caer el sitio

Falta el índice MySQL: reconoce la consulta que hace caer el sitio

¿El sitio de repente se vuelve lento sin una implementación reciente? Antes de agregar memoria, busque la consulta que analiza millones de filas; una fila EXPLAIN suele ser suficiente.

Redacción Hébergeurs.eu 4 min Actualizado 19 jul. 2026

Viernes negro, 10:12 a. m.: el sitio de comercio electrónico muestra una ruleta. La CPU MySQL sube al 98%, PHP-FPM espera. Última publicación: hace cinco días. El equipo solicita una actualización de VPS. A las 11 a.m., un desarrollador ejecuta "EXPLAIN" en la solicitud de pago - tipo: TODOS, filas: 2,400,000. Falta índice en (estado, creado_at) desde que se agregó el filtro "órdenes pendientes".

Un dedo índice faltante no grita. Acumula hasta el día en que el volumen o el tráfico lo hacen audible. La buena noticia: la firma se puede leer en el registro lento y EXPLICAR, si sabe buscar antes de comprar equipo.

Firmas de una solicitud tóxica

En EXPLAIN, "escriba: TODO" indica un escaneo completo de la tabla. Un número enorme de "filas" en comparación con el resultado indica una selectividad deficiente o un índice ausente. "Usar clasificación de archivos" y "Usar temporal" son costosos en ORDER BY y GROUP BY. Los bloqueos repetidos indican una restricción secundaria.

Habilitar registro de consultas lento:


slow_query_log = 1

tiempo_consulta_largo = 1

log_queries_not_using_indexes = 1

Cuando rows_examined/rows_sent > 1000 en una ruta HTTP, tienes un candidato prioritario.

De consulta lenta a índice útil

Ejemplo simplificado:


SELECCIONAR * DE pedidos

DONDE estado = 'pendiente' Y creado_en > '2026-01-01'

PEDIR POR creado_en DESC LÍMITE 50;

Sin índice: escaneo de millones de filas. Índice compuesto adaptado:


CREAR ÍNDICE idx_orders_status_created EN pedidos (estado, creado_at);

Orden de las columnas: empates primero (status =), rangos segundo (created_at >), ORDENAR POR compatible si es posible para un escaneo de cobertura.

Herramientas: registro lento con mysqldumpslow, esquema de rendimiento, ruta de correlación APM y consulta. Reproducir con datos cercanos a los de producción: puesta en escena vacía.

Cuándo no indexar

En una tabla de unos pocos miles de filas, el escaneo sigue siendo rápido. Una columna cuasi única que ya tiene una clave principal no necesita un duplicado. En escrituras masivas, cada índice cuesta. Una rara solicitud de administrador prefiere el almacenamiento en caché o la desnormalización.

En sistemas compartidos, el registro lento a veces es inaccesible: síntoma de "límite de procesador alcanzado" sin detalles. En VPS, ajuste innodb_buffer_pool_size después de los índices, no antes.

La parte superior: el hardware oculta la consulta

Antes de cualquier actualización de host para un "sitio lento", solicite las tres solicitudes más lentas de los últimos siete días. A menudo, un "CREAR ÍNDICE" de diez minutos vale cien euros VPS. Consulte Conexiones de grupo y EXPLICAR PostgreSQL para conocer el equivalente de Postgres.

Decide y avanza sin puntos ciegos

Habilite el registro lento en producción con un umbral de un segundo y recopile una semana de datos antes de cualquier decisión sobre el hardware. Ejecute EXPLAIN en las cinco consultas de ruta críticas: pago, búsqueda, administración. Cree un índice compuesto, mida antes y después con una carga realista. Programe una revisión trimestral después de grandes importaciones de datos. Configure una alerta en rows_examined a través de APM para detectar la desviación antes del próximo pico comercial.

Preguntas frecuentes

¿Cómo detectar un índice faltante?

Active el registro de consultas lento y ordene por líneas examinadas. EXPLAIN muestra el tipo TODO o un índice no muy selectivo: tiempo de consulta elevado con filas_examinadas mucho más altas que filas_enviadas.

¿Deberían indexarse ​​todas las columnas WHERE?

No. Cree índices compuestos en orden de los filtros más selectivos. Demasiados índices ralentizan INSERTAR y ACTUALIZAR.

¿Puede un índice volverse inútil?

Sí: crecimiento de la tabla, cambio de consulta o índice redundante mediante el prefijo izquierdo. Revisar después de una importante importación o rediseño de búsqueda.

¿Es suficiente aumentar la RAM?

Temporalmente. Un análisis completo crece con los datos: el grupo de buffer oculta el análisis una vez, no la causa estructural.


El sitio no falla sin motivo: a menudo encuentra una consulta que EXPLAIN puede reconocer en una línea.

Compara proveedores europeos

Filtra por cumplimiento, ubicación y caso de uso — luego abre las fichas para verificar el alcance real.

Explorar el directorio
Blog

Lecturas relacionadas

Todos los artículos →