Есть база mysql с таблицей, в которой необходимо хранить громадные объёмы данных (100+ миллионов записей). Ключ в таблице составной из трёх полей - два varchar(35) плюс один int(11). Данные чаще всего читаются (поиск только по ключу, так что тут проще), относительно часто обновляются и добавляются. Изредка должно производиться добавление данных (хотел LOAD'ом) тоже немалого объёма (от 5 до 60 миллионов записей за раз, но обычно 5 миллионов и меньше). Версия мускула - 5.0.27.
Пробовал работать с такой табличкой. До 20 миллионов было нормально. Затем потребовалось залить ещё 80 миллионов. Залил LOAD'ом во временно созданную аналогичную таблицу без primary key, добавил данные из реальной таблицы. Пустил добавление primary key и колом встала не только база, но и вся машина.

Есть ли у кого идеи, как можно такое разрулить? СУБД сменить предложения не принимаются - нужен именно mysql. Partitioning тут тоже не поможет - в ключе есть варчары, а интовое поле имеет небольшой набор значений с большими отличиями по количеству записей.

дай догадаюсь - innodb? тогда решение добавить pk - фатально.  

Да нет, MyISAM таблица. Просто объёмы великоваты для мускула. 
Когда-нибудь он ключ таки добавил бы, но я не могу ждать этого днями и неделями. Потому ищу варианты...

Решение нашлось на офсайте мускула. 
Конечно, лучше бы вообще не нагружать мускул такими объёмами, но по условиям задачи базу менять нельзя, а объёмы уменьшить без глобальных изменений в обрабатывающем коде нереально.
Итак, решение в студию:

• флашим таблицы

  Код

  FLUSH TABLES;

• отключаем ключи во временной таблице (её структура полностью идентична структуре таблицы, куда надо засунуть данные - со всеми ключами)

  Код

  myisamchk --keys-used=0 -rq /path/to/db/tbl_new

• тащим из старой таблицы данные в новую

  Код

  insert into tbl_new select * from tbl_real;

• загружаем данные из файла

  Код

  LOAD DATA INFILE "/tmp/data.txt" REPLACE INTO TABLE tbl_new FIELDS TERMINATED BY ',' LINES TERMINATED BY "\n";

• восстанавливаем ключи

  Код

  myisamchk --sort_buffer_size=50M -rqq /path/to/db/tbl_new

   (без повышения размера буфера myisamchk быстро выругался на нехватку памяти - по дефолту у него буфер для сортировки всего 2Мб)
• флашим таблицы

  Код

  FLUSH TABLES;

• переименовываем старую таблицу

  Код

  alter table tbl_real rename to tbl_old;

• переименовываем новую таблицу

  Код

  alter table tbl_new rename to tbl_real;

На копирование 17 миллионов из реальной таблицы потребовалось менее получаса, на загрузку 80 миллионов из файла - около получаса, на восстановление ключей - ещё около получаса. Вполне приемлемые затраты времени. Особенно по сравнению с возможными.