Восстановление базы данных MySQL происходит очень медленно

Я только что купил новый домашний рабочий стол. У меня есть три базы данных MySQL, которые я хочу переместить. Я сбросил их все с помощью mysqldump, прежде чем снимать диск со старой машины.

Восстановление самой большой из баз данных занимает целую вечность (пока что это занимает 24 часа). Я восстанавливаю через:

mysql -uxxxx -p
Введите пароль: гггг
mysql> создать базу данных foo;
mysql> использовать foo;
mysql> начать транзакцию;
mysql>\. <файл дампа>

Я молюсь, чтобы я не забыл совершить когда это закончится!

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

Могу ли я что-нибудь сделать, чтобы ускорить восстановление? Должен ли я был сделать резервную копию по-другому - я просто использовал ванильный mysqldump командная строка, с --skip-столбец-статистика поскольку в противном случае дамп не сработает, как это было предложено в этот ответ stackoverflow.

Для справки: новая машина работает под управлением Windows 10 и MySQL 8.0.25 Community; на старой машине работали Windows 7 и MySQL 5.6.22.

Глядя на файлы дампа более внимательно (чтобы найти версию сервера), я вижу, что таблицы создаются с их индексами, за которыми следует множество операторов INSERT INTO. Это не кажется особенно умным. Есть ли способ вызвать mysqldump создать скрипт, который:

1. Создает таблицы без индексов
2. Вставляет строки; а потом
3. Создает индексы.

что может показаться лучшим подходом при восстановлении базы данных. (Немного удивительно, что это не значение по умолчанию!) Я предполагаю, что это возможно с MySQL - я использую SQLLite в течение последних 3 лет, и это, безусловно, возможно.

Обновлять

этот вопрос не полностью ответил Как ускорить восстановление MySQL из файла дампа?, так как этот вопрос, в частности, относится к таблицам MyISAM, а у меня InnoDB. (Извинения. Вероятно, мне следовало упомянуть механизм хранения в моем первоначальном вопросе.)

Однако этот ответ мотивировал и информировал мои попытки решить вопросы, которые я документирую в своем собственном ответе ниже.

В конце концов я перестал ждать завершения импорта после > 24 часов.

Я изменил сценарии, сгенерированные mysqldump чтобы создавать таблицы без вторичных индексов и создавать индексы только тогда, когда все ВСТАВЛЯТЬ заявления были выполнены.С этим изменением импорт был завершен, когда я проверил через три часа после запуска.

Затем я дополнительно изменил сценарий, чтобы вставить строки в транзакцию, добавив УСТАНОВИТЬ АВТОКОММИТ = 0; НАЧАТЬ СДЕЛКУ; в начале и СОВЕРШИТЬ; в конце. С этим изменением восстановление завершилось за 90 минут.

При редактировании сгенерированных дампов я заметил, что они включают

/*!40000 ALTER TABLE `xxx` DISABLE KEYS */;

и

/*!40000 ALTER TABLE `xxx` ENABLE KEYS */;

вокруг ВСТАВЛЯТЬ заявления. я посмотрел документация по этим командам и обнаружил, что они применяются только к таблицам MyISAM. документация по mysqldump утилита утверждает, что эти строки (включая разделители комментариев и магическое число 40000) генерируются, если вы укажете --disable-ключи в командной строке. В документации к утилите также говорится, что она добавит поведение «вставить все в одну транзакцию», которое я считаю желательным, если вы укажете --no-autocommit в командной строке.

Таким образом, я, вероятно, должен был сделать резервные копии с помощью

 mysqldump --no-autocommit...

По крайней мере в моем случае(mysqldump версия 8.0.25 и таблица InnoDb) --disable-ключи опция не имеет значения; ALTER TABLE ... ENABLE|DISABLE KEYS операторы (закомментированные и с магическим числом) генерируются всегда. я делать необходимо изменить сгенерированный дамп, чтобы создать таблицы без вторичных ключей, и добавить их сразу все ВСТАВИТЬ В заявления выполнены.