собственно есть табличка.
в ней 24 млн записей.
при генерации скрипта, который призван сделать "дамп", т.е. чтобы на другом сервере "развернуть" схему - как только доходит дело до этой таблички - средство , которым дамп делается - самоубивается.
т.е. объем текстового файла с sql запросами весом 1.6 гб - дописывает табличку до 75% и обрыв.
вопрос: а как правильно?
слышал /придумал варианты:
1) делать партирование по , например 1 млн записей - легко слить.
2) сделать выгрузку по 1 млн с удалением 1 млн. т.е. по мере выгрузки чистить таблицу. это для того, чтобы сделать потом "красиво" выгрузку структуры всей схемы - а данные заливать из Н+1 пакетов.
3) делать из консоли, мускул все умеет :)
4) переписать файлы, которые сохранил мускул , а потом на новом сервере их просто переписать, восстановив схему mysql в то же состояние.(на мой взгляд бред, но не пробовал еще. да и не факт, что на новом месте не будет нужных данных, которые не желательно терять).
5) ну еще много разного.

В общем хотелось бы услышать профи, как поступают в подобных случаях.

и еще раз постановка задачи:
Сделать скрипт - текст sql - чтобы можно выполнить на новом месте и получить все таблицы/вьюхи/процедуры/функции/события/триггеры/данные.

Спасибо, за конструктивные советы по делу.
п.с. потабличное сливание данных тоже пробовал - проблема та же - зависает от через чур большого размера файла - хотя пишут , что 24млн мускул может "легко", но работать с такой таблицей времяемко выходит. ну и проблема обратного восстановления - бинарные варианты не особо помогают. сами данные - более тренировочные , а не "реальные", но и терять их не очень охота. Цель которую преследую - тренировка и обучение - т.к. пока малые таблички на боевой системе , но пухнут стремительно. Решил научится до того, как припрет "решать", чтобы не делать этого "по горячему". данные нагенерил скриптом за месяц. теперь не могу слить, т.к.для продолжения экспериментов переезжаю на другой сервер.

miksoftJudeсредство , которым дамп делаетсяЧто за средство?

Не так давно я налетал на случай, когда некое "средство" падало, когда размер файла дампа доходил до 2 ГБ.
Выяснилось, что проблема была фундаментальная - в размере целых чисел в PHP на 32-битной платформе.
Решить смогли только сокращением объема данных, благо, что нашлось много мусора, который можно было зачистить.
пока SQL Manager 2007
еще пробую dbforge. но пока в процессе. если получится - отпишу.
пару раз ловил "out of memory" - думаю что нужно, для чистоты эксперимента, сделать рестарт и повыгружать все лишнее для освобождения ресурсов.
возможно проблема как раз в "средстве". пока не разобрался. с администрированием знаком слабо - пока изучаю - пришлось
собственно поэтому и вопросы - т.к. хотелось бы после применения "подходов" потом не гуглить вопросы "и шо нам теперь со всем этим делать?" а заранее знать ответ и предоставить людям варианты решений.

miksoftJude,

а почему бы не попробовать штатный mysqldump ?
ну он в п.3 - попробую.
все по порядку.
не все админы им пользуются - нужно в начале другие средства проверить.
просто было интересно, как у людей делается.

еще вопрос вдогонку.
получаются разные файлы в зависимости от того, каким средством сделал дамп.
от 1 гб до 1.6 гб.
Пока пытаюсь понять ЧЕМ можно просмотреть скрипт, т.к. обычные редакторы сильно неторопливо работают, или откровенно не справляются с задачей.
чем обычно проверяют столь большие файлы с запросами?
п.с.
коллега подсказал тотал коммандер с каким-то аддоном - пока ищу.

miksoftJudeполучаются разные файлы в зависимости от того, каким средством сделал дамп.
от 1 гб до 1.6 гб.Могу предположить, что используются разные формы INSERT-а - однострочная и многострочная. Так же может отличаться форматирование, пробелы и т.п.
Еще могут быть разные кодировки, например, русский текст в UTF-8 почти вдвое больше, чем в win1251.
пока с целью проверки целостности данных выбрал запросом ид последней строки большой таблички, и его попробовал найти через поиск в тексте. в некоторых дампах нашел, у части нет. так понимаю, что в некоторых случаях просто был обрыв процесса записи.

Спасибо всем откликнувшимся за помощь. теперь буду изучать какие подходы хороши в моем случае.

отдельное спасибо за select into Outfile - не знал. буду проверять.