Почему импорт файла .sql размером 12 ГБ занимает более 36 часов?

16

Я ждал в течение 36 часов для импорта файла .sql размером 12 ГБ с помощью простой type site.sql | mysqlкоманды. Я вижу, что ibdata1растет все еще, в настоящее время почти 40 ГБ.

Учитывая, что триггеры и хранимые процедуры находятся в конце .sql, я только думаю, что MySQL должен добавлять данные и ключевые индексы.

Site.sql был создан с помощью этой команды с другого сервера:

mysqldump -R -e --databases site --add-drop-database --add-create-database --add-drop-table -C --single-transaction --triggers

Что так долго?

mysql mysql-5 mariadb servermanfail
источник
3
сколько процессоров занимает mysql? Если это низкое значение, это, вероятно, означает, что вы привязаны к диску
Дерек Дауни
2
файлы .sql на самом деле не так быстро импортируются ... на самом деле быстрее выгрузить дамп с разделителями табуляции или CSV, а затем создать пустую базу данных и использовать LOAD DATA INFILE. Кроме того, когда вы перемещаете всю базу данных, см. Мой ответ: перемещение баз данных между серверами, если вы используете одну и ту же основную версию. (особенно если вам нужно прервать и перезапустить)
Джо

Ответы:

23

Попробуй это:

$ ps -ef|grep [m]ysql

Затем идентифицируйте идентификатор процесса

$ strace -cp <pid>

Оставьте это на 10 секунд или минуту ^C. Это скажет вам, где процесс тратит свое время, например, он может просто ждать диск, если вы видели readи writeдоминировали.

Gaius
источник
4
+1, потому что я только что выучил новую команду (strace): P Edit: ну дерьмо, по умолчанию на моем Mac недоступно.
Дерек Дауни
2
Это фантастический инструмент вместе с GDB. Я не говорю людям, что их приложение больше зависало; Я говорю им точно, на чем он застрял или крутится, или из ядра скажу им строку кода и имя исходного файла. Еще более мощным является dtrace.
Гай
3
Strace - это Linux, а Solaris - это ферма. Dtrace доступен на Mac.
Гай
так что, это. собираюсь пойти читать об этом сейчас.
Дерек Дауни
Осторожно: хорошая команда, чтобы знать, но будьте осторожны, эта команда разбила мой экземпляр MySQL. Не знаю почему. До сбоя MySQL сервер перестал отвечать на несколько минут.
dabest1
7

Есть ли у вас таблицы InnoDB с первичным ключом

  1. содержащие несколько столбцов?
  2. имея широкий VARCHAR?
  3. и много неуникальных индексов?
  4. один или несколько неуникальных индексов с широким ключом?

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

Еще одно соображение: действительно ли сумма страниц данных InnoDB значительно меньше, чем страниц индекса InnoDB?

Вы можете узнать это с помощью этого запроса (в МБ):

SELECT SUM(data_length)/POWER(1024,2) InnoDBData,
SUM(index_length)/POWER(1024,2) InnoDBIndexes
FROM information_schema.tables WHERE engine='InnoDB';

Дополнительное соображение: у вас включена двоичная регистрация на сервере БД, который вы загружаете? Если вы, пожалуйста, сделайте это на сервере, который вы загружаете:

mysql -h... -u... -p... -A -e"SET sql_log_bin=0; source site.sql"

Надеюсь, это поможет !!!

RolandoMySQLDBA
источник
6

Вы уверены, что таблицы, в которых вы читаете, не имеют триггеров, индексов и ограничений? На каком оборудовании и ОС вы работаете? Как настроено ваше хранилище?

Я более знаком с оракулом, но импорт 12G на таблицы без триггеров, индексов и ограничений должен легко идти с 200 ГБ / ч. Один единственный триггер может превратить процесс в улитку, в зависимости от того, что делает этот триггер ...

надеюсь, это поможет

ik_zelf
источник