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
.jpeg)
