Какие настройки mysql влияют на скорость загрузки данных INFILE?

Question

Позвольте мне настроить ситуацию. Мы пытаемся вставить скромно большое количество строк (примерно 10-20 млн. В день) в скромно широкую таблицу MyISAM:

+--------------+--------------+------+-----+---------+-------+
| Field        | Type         | Null | Key | Default | Extra |
+--------------+--------------+------+-----+---------+-------+
| blah1        | varchar(255) | NO   | PRI |         |       | 
| blah2        | varchar(255) | NO   | PRI |         |       | 
| blah3        | varchar(5)   | NO   | PRI |         |       | 
| blah4        | varchar(5)   | NO   | PRI |         |       | 
| blah5        | varchar(2)   | NO   | PRI |         |       | 
| blah6        | varchar(2)   | NO   | PRI |         |       | 
| blah7        | date         | NO   | PRI |         |       | 
| blah8        | smallint(6)  | NO   | PRI |         |       | 
| blah9        | varchar(255) | NO   | PRI |         |       | 
| blah10       | bigint(20)   | YES  |     | NULL    |       | 
+--------------+--------------+------+-----+---------+-------+

Единственный индекс, кроме колоссального первичного ключа, находится в поле blah7, поле даты. Мы используем LOAD DATA INFILE и видим, что мне показалось довольно ужасной производительностью, около 2 часов для загрузки данных. Я был убежден, что LOAD DATA INFILE был на несколько порядков быстрее.

Интересно, что у нас есть несколько менее полных таблиц (5-6 полей), в которые мы также используем LOAD DATA INFILE для пакетной обработки данных, и мы видим гораздо лучшую производительность для них. Количество записей немного меньше, что наводит меня на мысль о том, что мы загружаемся до предела размера буфера, когда загружаем большую таблицу, и вынуждены идти на диск (и действительно, что еще, кроме перехода на диск, объясните такое медленное время загрузки?).

... что подводит меня к моему вопросу. Какие настройки my.cnf наиболее важны при работе с командами LOAD DATA INFILE?

Answer 1

Вставка в индексы в целом убивает производительность. Возможно, лучше удалить индекс перед вставкой данных и переиндексировать после вставки.

С http://forum.percona.com/s/m/983/:

Обычно MySQL достаточно быстрая загрузка данные в таблице MyISAM, но есть исключение, когда оно не может перестроить индексы по сортировке, но строит вместо этого они ряд за рядом. Может быть происходит из-за неправильной конфигурации (т.е. слишком маленький myisam_max_sort_file_size или myisam_max_extra_sort_file_size) или может быть просто отсутствие оптимизации, если у вас большой (не вписывается в память) ПЕРВИЧНЫЕ или УНИКАЛЬНЫЕ индексы.

Также проверьте http://www.mysqlperformanceblog.com/2007/05/24/predicting-how-long-data-load-would-take/ и http://www.linuxtopia.org/online_books/database_guides/mysql_5.1_database_reference_guide/insert-speed.html.

Answer 2

Если ваша таблица MyISam и данные добавляются в непустую таблицу, то bulk_insert_buffer_size имеет значение

MyISAM использует специальный древовидный кэш для ускорения массовых вставок для LOAD DATA INFILE при добавлении данных в непустые таблицы. Переменная BULK_INSERT_BUFFER_SIZE ограничивает размер дерева кэша в байтах на поток. Установка в 0 отключает эту оптимизацию. Значение по умолчанию составляет 8 МБ. Максимальное значение составляет 4 ГБ.

Если данные добавляются в непустую таблицу, настройка переменной bulk_insert_buffer_size может ускорить вставку данных. Обычно это показывает улучшение, когда данные для вставки превышают 10 тыс. Строк. Но трудно сказать, каково правильное значение, поэтому попробуйте выполнить дополнительные значения размера буфера и попробуйте.

Кроме того, улучшение производительности будет более очевидным, если также установить следующие переменные:

• MYISAM_SORT_BUFFER_SIZE
• KEY_BUFFER_SIZE

Вам также следует рассмотреть возможность отключения индексов перед загрузкой данных с помощью следующей команды alter table:

alter table t disable keys;

Answer 3

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