2016-01-07 1 views
6

Я только что загрузил новейшую версию MySQL Workbench (6.3.6) и попытался экспортировать удаленную таблицу (на Google CloudSQL) в csv с помощью нового мастера экспорта табличных данных. В таблице было около 600 000 строк, а конечный загруженный размер был около 75 МБ. Это заняло 7,5 часа.Экспорт данных таблицы workbench MySQL чрезвычайно медленный

Я понимаю, что я могу использовать Консоль разработчика Google для выполнения этого экспорта (что я сделал и заняло около 15 секунд), но, похоже, что-то не так с MySQL Workbench. Может ли быть проблема с конфигурацией, которая вызывает это так медленно?

+1

Любопытно, вы экспортировали файл на локальную или удаленную машину? Имеет ли это изменение? –

+0

Можете ли вы запустить traceroute (mtr is awesome) между вами и IP-адресом экземпляра, чтобы диагностировать латентность сети? – Nick

+0

https://stackoverflow.com/questions/33296569/mysql-workbench-table-data-import-wizard-extermely-slow Повторите эту ссылку –

ответ

0

Описание: Workbench очень медленно экспортирует большие наборы данных через мастер экспорта CSV. Непропорционально медленный компромисс с меньшим набором. Однако это то, с чем я столкнулся раньше с .NET.

Как это сделать: Получите таблицу с 15 или около того записей или более и экспортируйте ее через мастер. Обратите внимание, сколько времени потребуется, а затем экспортируйте подмножество этих данных и посмотрите, как затраченное время не коррелирует линейно с количеством строк.

Предложенные исправить: Что-то я заметил, при создании экспорта приложений CSV является то, что структура MS .NET не может справиться с огромными строками очень хорошо, и, как правило, выполняют плохо, как результат.

Я нашел решение, хотя. Когда вы создаете огромную строку в дампе в файл, когда вы его генерируете, вместо того, чтобы создавать одну огромную строку и записывать ее в файл сразу же после завершения экспорта, я получаю гораздо лучшую производительность, делая только несколько сто строк CSV, сгенерированных за один раз, записать их в файл и сбросить буфер, на который вы записывали сгенерированные данные.

Я бы рекомендовал писать временный файл, а затем переименовать/переместить его на указанный пользователем. Write to temp, а затем move/rename - это способ, которым Photoshop и некоторые другие приложения сохраняют свои данные. И записи x строк и flushing, которые я обнаружил при разработке, намного быстрее, чем пытаться заставить .NET управлять строкой 20 МБ.