Errores comunes en MySQL que matan el rendimiento (y cómo evitarlos)


Muchas bases de datos no son lentas por el servidor, la RAM o el disco.

Son lentas por decisiones pequeñas que se repiten durante meses… hasta que todo empieza a ir mal.

En este artículo vamos a repasar los errores más comunes en MySQL que destruyen el rendimiento sin que te des cuenta, con ejemplos reales y soluciones claras.

👉 Si usas MySQL en proyectos reales, te vas a reconocer en más de uno.


1️⃣ Usar SELECT * en producción (el clásico silencioso)

Este es probablemente el error más frecuente.

SELECT *
FROM orders
WHERE user_id = 42
ORDER BY created_at DESC
LIMIT 10;

❌ Por qué es un problema

  • Traes columnas que no usas
  • Aumentas transferencia de datos
  • Rompes posibles índices “covering”
  • Penaliza memoria y red

✅ Cómo hacerlo bien

Selecciona solo lo necesario:

SELECT id, total, created_at
FROM orders
WHERE user_id = 42
ORDER BY created_at DESC
LIMIT 10;

📌 Regla senior:

SELECT * solo es aceptable en debugging o scripts internos, nunca en consultas críticas.

2️⃣ No usar índices (o usarlos mal)

Ya lo vimos en el post anterior, pero aquí va el error típico:

SELECT *
FROM users
WHERE email = 'test@email.com';

❌ Sin índice en email

→ MySQL hace table scan

✅ Solución

CREATE INDEX idx_users_email ON users(email);

📌 Si una columna aparece frecuentemente en WHERE, JOIN u ORDER BY, probablemente necesita índice.


3️⃣ Indexar columnas con baja cardinalidad

Otro error muy común:

INDEX(status)

Donde status solo tiene:

  • active
  • inactive

❌ Por qué no funciona

  • MySQL tiene que leer casi toda la tabla igualmente
  • El índice no filtra lo suficiente
  • A veces es más lento que no tener índice

✅ Solución

  • No indexar columnas con pocos valores
  • O usarlas como segunda columna en un índice compuesto

4️⃣ Abusar de OFFSET en tablas grandes

Este error aparece mucho en paginaciones.

SELECT *
FROM posts
ORDER BY created_at DESC
LIMIT 20 OFFSET 50000;

❌ Qué está pasando realmente

MySQL:

  • lee 50.020 filas
  • descarta 50.000
  • devuelve 20

👉 Esto escala muy mal.

✅ Alternativa correcta (paginación por cursor)

SELECT *
FROM posts
WHERE created_at < '2024-01-01 10:30:00'
ORDER BY created_at DESC
LIMIT 20;

📌 Regla real:

OFFSET grande = rendimiento muerto.

5️⃣ No usar EXPLAIN antes de optimizar

Optimizar sin EXPLAIN es adivinar.

EXPLAIN
SELECT id, email
FROM users
WHERE email = 'x@x.com';

Qué mirar siempre:

  • type → evita ALL
  • key → índice usado
  • rows → filas estimadas
  • Extra → “Using filesort” = alerta

📌 Si no usas EXPLAIN, estás optimizando a ciegas.


6️⃣ JOIN mal diseñados

Este error es letal en sistemas legacy.

SELECT *
FROM orders o
JOIN users u ON o.user_id = u.id;

❌ Problemas comunes

  • JOIN sin índice
  • JOIN innecesario
  • JOIN trayendo columnas que no se usan

✅ Buenas prácticas

  • Indexa claves foráneas
  • Selecciona columnas explícitas
  • Pregunta: ¿realmente necesito este JOIN?

7️⃣ Usar funciones en columnas indexadas

Ejemplo típico:

SELECT *
FROM users
WHERE DATE(created_at) = '2024-01-01';

❌ Error grave

  • MySQL NO puede usar el índice
  • Convierte la consulta en table scan

✅ Solución correcta

SELECT *
FROM users
WHERE created_at >= '2024-01-01'
  AND created_at < '2024-01-02';

📌 Nunca envuelvas columnas indexadas en funciones.


8️⃣ Demasiados índices “por si acaso”

Error clásico en sistemas antiguos:

INDEX(name),
INDEX(email),
INDEX(status),
INDEX(created_at),
INDEX(updated_at)

❌ Consecuencias

  • INSERT más lento
  • UPDATE más lento
  • DELETE más lento
  • Tablas más grandes

✅ Solución

  • Elimina índices no usados
  • Indexa consultas reales
  • Revisa con SHOW INDEX

9️⃣ No limpiar datos antiguos

Tablas que crecen sin control:

  • logs
  • eventos
  • sesiones
  • auditorías

❌ Problema

Aunque la consulta sea buena:

  • más filas = más coste
  • más disco
  • más cache inútil

✅ Solución

  • Archivar datos antiguos
  • Tablas históricas
  • Borrados programados

🔟 Pensar que “el problema es el servidor”

Este es el error mental más peligroso.

❌ “Subamos la RAM”

❌ “Metamos más CPU”

👉 El 80 % de los problemas son:

  • consultas mal escritas
  • índices mal pensados
  • diseño pobre

📌 Optimiza antes de escalar.


Checklist rápido de rendimiento MySQL

✔ Evita SELECT *

✔ Usa índices con criterio

✔ Revisa cardinalidad

✔ Usa EXPLAIN siempre

✔ Evita OFFSET grande

✔ No funciones en WHERE

✔ Limpia datos antiguos

✔ Mide antes de cambiar

Conclusión

MySQL es muy rápido…

si no le disparas en el pie.

La mayoría de los problemas de rendimiento:

  • no son bugs
  • no son falta de hardware
  • son malas decisiones acumuladas

La buena noticia:

👉 casi todos estos errores son fáciles de corregir.