Errores comunes al migrar de MySQL 5.6 o 5.7 a MySQL 8.0

Compatibilidad, collation, optimizador y validaciones que suelen subestimarse al planificar una migración mayor.

Migrar a MySQL 8.0 no es solo cambiar de versión. El salto toca compatibilidad, comportamiento del optimizador, collations, autenticación y expectativas de aplicaciones que llevan años funcionando de cierta manera. Tratarlo como un upgrade cosmético es una forma bastante eficiente de comprar problemas nuevos.

El error de base suele ser el mismo: asumir que si el esquema importa, entonces la aplicación ya está lista. En migraciones reales, lo delicado rara vez está solo en las tablas. También viven ahí procedimientos, vistas, funciones, modos SQL, consultas heredadas y supuestos históricos que nadie había cuestionado porque el motor antiguo todavía los toleraba.

Qué suele romper primero

Uno de los problemas más comunes aparece en compatibilidad funcional. Consultas antiguas, funciones heredadas o configuraciones tolerantes empiezan a comportarse distinto. A eso se suma el cambio de collations y ciertos ajustes de autenticación que pueden parecer menores hasta que impactan integración con backend o usuarios reales.

Cambio de plugin de autenticación

MySQL 8.0 usa caching_sha2_password por defecto en lugar de mysql_native_password. Esto rompe conexiones de clientes o drivers que no han sido actualizados.

sqlCopiar-- Verificar plugin actual de usuarios
SELECT user, host, plugin FROM mysql.user;

-- Cambiar a native si el driver no soporta SHA2
ALTER USER 'usuario'@'host' IDENTIFIED WITH mysql_native_password BY 'password';

Criterio REACTIV: No recomendamos forzar mysql_native_password de forma global como parche rápido. Lo correcto es actualizar el driver del backend. Si el driver es incompatible con SHA2, eso es una deuda técnica que la migración está descubriendo, no generando.

Collations: el problema silencioso

MySQL 8.0 introduce utf8mb4_0900_ai_ci como collation por defecto, reemplazando utf8mb4_unicode_ci. Esto puede provocar:

• Errores de comparación de strings que antes pasaban
• Incompatibilidad en JOIN entre tablas con collations distintas
• Problemas al migrar dumps entre instancias con configuración diferente

sqlCopiar-- Verificar collation actual del servidor
SHOW VARIABLES LIKE 'collation%';

-- Verificar collations por tabla
SELECT table_name, table_collation 
FROM information_schema.tables 
WHERE table_schema = 'tu_base_de_datos';

-- Forzar collation consistente al restaurar
SET NAMES utf8mb4 COLLATE utf8mb4_unicode_ci;

El optimizador también cambia la conversación

MySQL 8.0 introdujo un optimizador de consultas completamente reescrito. Consultas que antes parecían aceptables pueden degradarse o cambiar de plan de ejecución. Si no se mide antes y después, la migración queda expuesta a problemas que solo aparecen bajo carga, cuando ya no estás comparando laboratorio sino operación real.

sqlCopiar-- Capturar plan de ejecución ANTES de migrar (en MySQL 5.7)
EXPLAIN FORMAT=JSON SELECT * FROM pedidos WHERE cliente_id = 123;

-- Mismo query en MySQL 8.0 para comparar
EXPLAIN ANALYZE SELECT * FROM pedidos WHERE cliente_id = 123;

Nota: EXPLAIN ANALYZE es exclusivo de MySQL 8.0 y entrega tiempos reales de ejecución. Es una de las herramientas más útiles del nuevo motor.

Cambios en sql_mode que rompen consultas heredadas

sqlCopiar-- Ver sql_mode activo
SELECT @@GLOBAL.sql_mode;

-- sql_mode por defecto en 8.0 (más estricto):
-- ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES, NO_ZERO_IN_DATE,
-- NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_ENGINE_SUBSTITUTION

-- Temporalmente compatibilizar (NO como solución permanente):
SET GLOBAL sql_mode = 'STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION';

Errores comunes en este tipo de migración

• Asumir compatibilidad solo porque el esquema restauró sin errores
• No revisar procedimientos almacenados, vistas y funciones definidas por usuario
• Ignorar cambios de collation y sql_mode
• No medir planes de ejecución antes y después de migrar
• Validar solo arranque del servicio y no flujos funcionales reales
• Usar mysqldump sin --routines --triggers --events y perder lógica del servidor
• No verificar compatibilidad del driver de conexión con caching_sha2_password

Checklist pre-migración

1. Inventario de objetos

sqlCopiar-- Contar objetos por tipo en la base de datos
SELECT 
 'TABLES' AS tipo, COUNT(*) AS total FROM information_schema.tables WHERE table_schema = 'tu_bd' AND table_type = 'BASE TABLE'
UNION ALL
SELECT 'VIEWS', COUNT(*) FROM information_schema.views WHERE table_schema = 'tu_bd'
UNION ALL
SELECT 'ROUTINES', COUNT(*) FROM information_schema.routines WHERE routine_schema = 'tu_bd'
UNION ALL
SELECT 'TRIGGERS', COUNT(*) FROM information_schema.triggers WHERE trigger_schema = 'tu_bd';

2. Validación con mysqlcheck

bashCopiar# Antes de migrar, correr en la instancia 5.7
mysqlcheck --all-databases --check --user=root --password

# Verificar que no hay tablas con formato incompatible
mysqlcheck --all-databases --check-upgrade --user=root --password

3. Dump completo con todos los objetos

bashCopiarmysqldump --single-transaction --routines --triggers --events --hex-blob --set-gtid-purged=OFF -u root -p nombre_base > backup_previo_migracion.sql

Qué conviene validar antes de salir a producción

No basta con levantar el servicio; hay que probar flujos reales, integración con backend, tiempos de respuesta y recuperación ante rollback si algo falla. Una migración mayor no se cierra cuando la instancia responde ping; se cierra cuando el sistema sigue funcionando de forma defendible.

sqlCopiar-- Test básico de integridad post-migración
CHECK TABLE nombre_tabla EXTENDED;

-- Verificar que no quedaron tablas en formato antiguo
SELECT table_name, row_format 
FROM information_schema.tables 
WHERE table_schema = 'tu_bd' 
 AND row_format NOT IN ('Dynamic', 'Compressed');

Lo que este artículo no cubre (y por qué)

• Replicación maestro-esclavo durante la migración: requiere coordinación de GTIDs y puede implicar tiempo sin replicación. Es un artículo completo por sí solo.
• Migración desde MySQL 5.6 directo a 8.0: Oracle no soporta salto directo; se requiere pasar por 5.7 como versión intermedia. Si estás en 5.6, eso cambia el orden de operaciones.
• MySQL 8.0 → 8.4 LTS: MySQL 8.4 es la rama LTS actual. Si vas a migrar hoy, vale la pena evaluar si conviene apuntar directamente a 8.4 LTS en vez de 8.0.
• MariaDB como alternativa: la divergencia entre MySQL y MariaDB en versiones recientes es suficientemente relevante como para tratarse por separado.

Checklist de salida (si solo vas a revisar cinco cosas)

1. Inventario completo de tablas, vistas, procedimientos, triggers y eventos
2. Pruebas funcionales reales con el backend conectado (no solo import exitoso)
3. Revisión de collations y sql_mode en cada base de datos y tabla crítica
4. Comparación de planes de ejecución en queries de alto volumen
5. Rollback claro y probado antes de abrir la ventana de cambio

Conclusión

La migración correcta se hace con inventario, pruebas, métricas y ventana controlada. Si se hace por impulso, normalmente termina costando más de lo que prometía ahorrar. En MySQL 8.0 el problema no es que el motor cambie; el problema es descubrir demasiado tarde todo lo que tu entorno heredado daba por sentado.

¿Tu migración ya está planificada o recién está empezando a doler? Conversemos.