Nó phụ thuộc vào cách bạn định nghĩa "nhanh nhất".
Như Joel nói, thời gian dành cho nhà phát triển rất tốn kém. Mysqldump hoạt động và xử lý rất nhiều trường hợp mà bạn phải tự xử lý hoặc dành thời gian đánh giá các sản phẩm khác để xem liệu chúng có xử lý được không.
Các câu hỏi thích hợp là:
Lược đồ cơ sở dữ liệu sản xuất của bạn thay đổi bao lâu một lần?
Lưu ý: Tôi đang đề cập đến việc thêm, xóa hoặc đổi tên bảng, cột, chế độ xem và những thứ tương tự, tức là những thứ sẽ phá vỡ mã thực tế.
Bạn cần đưa dữ liệu sản xuất vào môi trường phát triển bao lâu một lần?
Theo kinh nghiệm của tôi, không thường xuyên lắm. Tôi thường thấy rằng mỗi tháng một lần là quá đủ.
Mysqldump mất bao lâu?
Nếu nó ít hơn 8 giờ nó có thể được thực hiện qua đêm như một công việc cron. Vấn đề đã được giải quyết.
Bạn có cần tất cả dữ liệu không?
Một cách khác để tối ưu hóa điều này là chỉ cần lấy một tập hợp con dữ liệu có liên quan. Tất nhiên điều này yêu cầu một tập lệnh tùy chỉnh được viết để có được một tập hợp con các thực thể và tất cả các thực thể liên quan có liên quan nhưng sẽ mang lại kết quả cuối cùng nhanh nhất. Tập lệnh cũng sẽ cần được duy trì thông qua các thay đổi lược đồ, vì vậy đây là cách tiếp cận tốn thời gian nên được sử dụng như một phương sách cuối cùng tuyệt đối. Mẫu sản xuất phải đủ lớn để bao gồm mẫu dữ liệu đủ rộng và xác định bất kỳ vấn đề hiệu suất tiềm ẩn nào.
Kết luận
Về cơ bản, chỉ sử dụng mysqldump cho đến khi bạn hoàn toàn không thể. Dành thời gian cho một giải pháp khác không phải là thời gian để phát triển.
