Cela dépend de la façon dont vous définissez "le plus rapide".
Comme le dit Joel, le temps des développeurs coûte cher. Mysqldump fonctionne et gère de nombreux cas que vous auriez autrement à gérer vous-même ou à passer du temps à évaluer d'autres produits pour voir s'ils les traitent.
Les questions pertinentes sont :
À quelle fréquence le schéma de votre base de données de production change-t-il ?
Remarque : Je fais référence à l'ajout, la suppression ou le renommage de tables, de colonnes, de vues, etc., c'est-à-dire des choses qui cassent le code réel.
À quelle fréquence devez-vous placer des données de production dans un environnement de développement ?
D'après mon expérience, pas très souvent du tout. J'ai généralement trouvé qu'une fois par mois est plus que suffisant.
Combien de temps prend mysqldump ?
Si c'est moins de 8 heures, cela peut être fait du jour au lendemain en tant que tâche cron. Problème résolu.
Avez-vous besoin de toutes les données ?
Une autre façon d'optimiser cela consiste simplement à obtenir un sous-ensemble de données pertinent. Bien sûr, cela nécessite l'écriture d'un script personnalisé pour obtenir un sous-ensemble d'entités et toutes les entités associées pertinentes, mais donnera le résultat final le plus rapide. Le script devra également être maintenu via des modifications de schéma, il s'agit donc d'une approche chronophage qui doit être utilisée en dernier recours absolu. Les échantillons de production doivent être suffisamment volumineux pour inclure un échantillon de données suffisamment large et identifier tout problème de performances potentiel.
Conclusion
Fondamentalement, utilisez simplement mysqldump jusqu'à ce que vous ne puissiez absolument plus le faire. Passer du temps sur une autre solution est du temps non consacré au développement.
