Errores más comunes al usar particionado en MySQL (y cómo evitarlos)

El particionado en MySQL es una herramienta poderosa, pero también tiene varias reglas “ocultas” que suelen generar errores frustrantes.

1. La clave primaria no incluye la columna de partición

Este es el clásico:

PARTITION BY RANGE (anio_publicacion)

PRIMARY KEY (id_libro)

Error: A PRIMARY KEY must include all columns in the table's partitioning function

Solución

PRIMARY KEY (id_libro, anio_publicacion)

MySQL necesita garantizar unicidad global entre particiones. Por eso tiene que ser primary key la partición. 

2. Índices UNIQUE que no incluyen la columna de partición

No solo afecta a la PK:

UNIQUE (email)

También falla si email no incluye la columna de partición.

Solución: 

UNIQUE (email, anio_publicacion)

3. Pensar que el particionado reemplaza índices

Error conceptual muy común:

> “Particiono y ya no necesito índices”

❌ Incorrecto

Particionado → reduce datos a escanear

Índices → optimizan acceso dentro de la partición

Se complementan, no compiten.

4. No usar la columna de partición en las consultas

Ejemplo:

SELECT * FROM logs WHERE usuario = 'Juan';

MySQL tiene que escanear todas las particiones.

Mejor:

SELECT * FROM logs 

WHERE fecha >= '2026-01-01'

AND usuario = 'Juan';

Activa partition pruning

5. Definir mal los rangos (RANGE)

Ejemplo peligroso:

PARTITION p2023 VALUES LESS THAN (2023),

PARTITION p2024 VALUES LESS THAN (2024)

 ¿Dónde van los valores de 2023? (error lógico)

Correcto:

PARTITION p2023 VALUES LESS THAN (2024)

6. Olvidarse de MAXVALUE

PARTITION p2024 VALUES LESS THAN (2025)

¿Qué pasa con datos futuros?

Solución:

PARTITION pFuture VALUES LESS THAN MAXVALUE

Evita errores al insertar nuevos datos.

7. Usar particionado en tablas pequeñas

Overkill total.

Problema:

• Más complejidad
• Sin beneficios reales
• Incluso puede empeorar performance

8. Pensar que particionado = sharding

Error conceptual importante.

Diferencia

Particionado → dentro de una misma tabla (mismo servidor)

Sharding → distribución en múltiples servidores

9. Usar funciones no determinísticas o inválidas

Ejemplo:

PARTITION BY RANGE (YEAR(NOW()))

❌ No permitido

10. Problemas con AUTO_INCREMENT

Cuando combinás:

• AUTO_INCREMENT
• PK compuesta
• Particionado

Puede volverse confuso

Tip:

El AUTO_INCREMENT:

• Debe estar en una clave indexada
• Y respetar la estructura de la PK

12. Creer que DELETE masivo es la mejor opción

DELETE FROM logs WHERE fecha < '2023-01-01';

Lento, bloqueante

Mejor con particionado:

ALTER TABLE logs DROP PARTITION p2022;

Instantáneo

El particionado en MySQL:

✔️ Puede mejorar muchísimo la performance

❌ Pero introduce restricciones de diseño importantes

La clave es entender que:

• No es transparente
• Afecta claves, índices y consultas
• Debe planificarse desde el diseño