Migration MySQL : contrôler performances et cohérence

Un import réussi ne suffit pas

Une migration MySQL n’est exploitable que si les données sont correctes, l’application fonctionne et les performances convenues restent possibles. Un import terminé sans erreur ne prouve pas entièrement ces conditions. Inventoriez versions, moteurs de stockage, schémas, index, collations, jeux de caractères, modes SQL, fuseaux, droits, triggers, routines et événements. Ajoutez les tâches externes et connexions applicatives. Définissez les exclusions et le responsable de l’approbation. Changer de plateforme peut modifier le comportement malgré des tables et des nombres de lignes identiques : conservez des critères d’acceptation écrits.

Vérifier restauration et limites du snapshot

Testez la restauration sur un environnement distinct. Un fichier de sauvegarde présent ne garantit pas la restauration correcte des schémas, routines et droits nécessaires. Une comparaison cohérente demande une frontière de snapshot précise. Avec des écritures continues, deux systèmes corrects peuvent afficher des nombres différents. Un mysqldump avec --single-transaction ne garantit pas automatiquement la cohérence des tables non transactionnelles ou face à du DDL simultané. Choisissez la méthode selon les moteurs, le volume et l’interruption acceptable. Documentez le retard éventuel de réplication et le dernier changement appliqué avant de comparer.

Contrôler le contenu, pas seulement les nombres

Cet exemple isolé crée deux tables temporaires avec les trois mêmes identifiants. Le montant de l’ID 2 diffère volontairement dans la cible. COUNT(*) est égal, mais le contenu est incorrect. Les montants utilisent ici des centimes entiers pour éviter une comparaison flottante. Exécutez le bloc uniquement dans une nouvelle connexion à une base MySQL de test et arrêtez-vous à la première erreur. C’est une fixture, pas un script de migration de production. Fermez la session pour supprimer les tables. Les règles réelles de précision du domaine restent à documenter séparément.

-- Synthetic data only. NEW session in a separate MySQL test database.
-- Never run in production. Stop at the first error; close the session afterwards.
CREATE TEMPORARY TABLE cg_migration_source (
    id INTEGER NOT NULL PRIMARY KEY, amount_cents INTEGER NULL
);
CREATE TEMPORARY TABLE cg_migration_target (
    id INTEGER NOT NULL PRIMARY KEY, amount_cents INTEGER NULL
);
INSERT INTO cg_migration_source VALUES (1,1000),(2,2500),(3,NULL);
INSERT INTO cg_migration_target VALUES (1,1000),(2,2501),(3,NULL);

SELECT 'source' AS dataset, COUNT(*) AS row_count FROM cg_migration_source
UNION ALL
SELECT 'target' AS dataset, COUNT(*) AS row_count FROM cg_migration_target;

-- Expected: one difference, id 2. NULL mismatches are tested explicitly.
SELECT s.id, s.amount_cents AS source_amount, t.amount_cents AS target_amount
FROM cg_migration_source s
LEFT JOIN cg_migration_target t ON t.id = s.id
WHERE t.id IS NULL
   OR s.amount_cents <> t.amount_cents
   OR (s.amount_cents IS NULL AND t.amount_cents IS NOT NULL)
   OR (s.amount_cents IS NOT NULL AND t.amount_cents IS NULL)
ORDER BY s.id;

-- Also check unexpected target IDs; a one-direction comparison is insufficient.
-- Expected: no rows for this fixture.
SELECT t.id FROM cg_migration_target t
LEFT JOIN cg_migration_source s ON s.id = t.id
WHERE s.id IS NULL
ORDER BY t.id;

Pour la migration réelle, contrôlez clés manquantes et supplémentaires dans les deux sens, valeurs NULL, montants, dates et relations sur le même snapshot convenu. Un échantillon ou un checksum simple n’apporte pas la même assurance qu’une comparaison intégrale. Précisez les colonnes et enregistrements vérifiés et les différences volontairement attendues. La réussite de cette petite fixture ne prouve pas l’exhaustivité d’une base client. Ajoutez les invariants applicatifs, notamment propriété et cohérence référentielle, et expliquez les écarts avant d’autoriser de nouvelles écritures de production dans la cible.

Comparer les performances dans les mêmes conditions

Avant la répétition, choisissez des recherches, rapports et écritures représentatifs. Mesurez source et cible avec données, paramètres, cache et profils de charge comparables. Examinez erreurs, verrous, plans et ressources en plus des durées. Un SELECT plus rapide ne compense pas une tâche manquante ou une transaction défaillante. Actualisez les statistiques si la méthode et la version l’exigent, puis testez les réglages applicatifs prévus pour la bascule. Conservez plusieurs mesures et des seuils convenus plutôt que d’accepter après coup toute différence au seul motif que l’import est terminé.

Planifier explicitement bascule et retour

Convenez des critères d’arrêt, fenêtre de maintenance, interruption acceptable, autorité de décision et contrôles après bascule. Dès que la cible accepte de nouvelles écritures, revenir à une ancienne source peut perdre les changements récents. Le retour doit donc traiter ces données via une réconciliation testée ou une pause contrôlée des écritures. Ne promettez pas une absence totale d’interruption sans architecture démontrée. Clôturez seulement après documentation des contrôles de données, d’application et de performance et approbation du responsable. Conservez les preuves réelles plutôt que de garantir une récupération non testée.

Poursuivre l’analyse

Un plan de requête ne représente qu’une partie du diagnostic. Les références ci-dessous relient l’analyse technique à un service SQL délimité. Les démonstrations utilisent des données fictives et non les résultats d’une mission client. Pour une demande, commencez par décrire le problème avec un contexte anonymisé, sans mot de passe, dump complet ni données personnelles.

• Analyser une requête MySQL lente avec EXPLAIN
• Choisir les index à partir de vraies requêtes Laravel
• Discuter de l’optimisation SQL
• Démonstration SQL reproductible
• Demander une analyse SQL