Зависи как дефинирате „най-бърз“.
Както казва Джоел, времето за разработчици е скъпо. Mysqldump работи и обработва много случаи, с които иначе би трябвало да се справите сами или да отделите време за оценка на други продукти, за да видите дали те се справят с тях.
Уместните въпроси са:
Колко често се променя схемата на вашата производствена база данни?
Забележка: Имам предвид добавяне, премахване или преименуване на таблици, колони, изгледи и други подобни, т.е. неща, които ще нарушат действителния код.
Колко често трябва да поставяте производствени данни в среда за разработка?
Според моя опит, изобщо не много често. По принцип открих, че веднъж месечно е повече от достатъчно.
Колко време отнема mysqldump?
Ако е по-малко от 8 часа, може да се направи за една нощ като cron работа. Проблемът е решен.
Имате ли нужда от всички данни?
Друг начин да оптимизирате това е просто да получите подходящ подмножество от данни. Разбира се, това изисква персонализиран скрипт да бъде написан, за да се получи подмножество от обекти и всички съответни свързани обекти, но ще доведе до най-бързия краен резултат. Скриптът също ще трябва да се поддържа чрез промени в схемата, така че това е отнемащ време подход, който трябва да се използва като абсолютна последна мярка. Производствените проби трябва да са достатъчно големи, за да включват достатъчно широка извадка от данни и да идентифицират евентуални проблеми с производителността.
Заключение
По принцип просто използвайте mysqldump, докато абсолютно не можете. Прекарването на време за друго решение е време, което не е изразходвано за разработване.
