На входе ланные в виде "ключ" (32 байта) "строка" (mediumblob). Ключи не уникальны.
На выходе нужно получить для каждого уникального "ключа" "строку" которая создана по специальному алгоритму из строк соответствующих данному ключу на входе.
Решаю - кладу все пары "ключ" - "строка" в таблицу, после завершения входного потока получаю из таблицы уникальные ключи, поочередно обрабатываю для каждого его строки и сохраняю в выходном файле.
Проблема - индексы сильно тормозят работу при большом количестве записей.
(количество записей около 7000000000, уникальных ключей около 20000000).
Существует ли какое-то более оптимальное решение (с mysql или без него)?

Данные поступают из программы которая обрабатывает другие данные, которые берет с жесткого диска.
При увеличении количества записей в таблице, резко растет время, затрачиваемое процессором на обмен с жестким диском, на котором находится файл индексов (других операций с ним в это время не производится).

miksoftmihail_13"строку" которая создана по специальному алгоритму из строк соответствующих данному ключуПро это тоже хотелось бы поподробнее. Одно дело простая конкатенация, и совсем другое, например, перемножить матрицы, хранящиеся в этих mediumblob-ах.
Если Вы хотите предложить update по ключу, то не стоит - объем данных и так превышает 4Gb, а после update размер файла еще и непредсказуемо вырастет (+ куча затрат на многократные чтения этого файла)

Если нет, то все равно врятли:
Строка имеет побитовую внутреннюю структуру, при слиянии объединенные данные сортируются по одному из полей, после чего сжимаются специальным алгоритмом (если он дает уменьшение длинны) и сохраняется с указанием сжато/не сжато.

miksoftmihail_13При увеличении количества записей в таблице, резко растет время, затрачиваемое процессором на обмен с жестким диском, на котором находится файл индексов (других операций с ним в это время не производится).Кэш индексов достаточного размера?
Если класть каждую запись отдельно (без, например, конкатенации записей с одним ключом), то нужен будет кэш порядка 70 ГБ, что явно многовато для простого сервера.
Если записи на лету группировать, то хватит примерно 200 МБ, но возрастет количество дисковых операций при группировке.
Конечно же кеша не хватает, даже если все оперативку отдам под кеш все равно не хватит.
(про группировку на лету уже сказал)

miksoftmihail_13объем данных и так превышает 4GbЭто на каком этапе?
На входе размер одних только ключей составит 4*7000000000=28ГБ.
Опечаточка вышла: 4Tb
(А индексы немного покороче - размер индекса ключа в таблице урезан до 6 байт)

miksoftЯ еще не понял задачу и всех условий, но уже есть ощущение, что СУБД тут не поможет и что нужно использовать просто файловую систему (конечно, не валить все в один каталог, а создать разумной глубины дерево) на SSD.
Задача в том, что есть некоторый объем данных, который заведомо не влезет в память, и даже его индексы не влезут в память, поэтому и то и другое придется держать на диске. Данные привязаны к ключам (к каждому ключу может быть привязано много записей данных). Данные привязанные к одному ключу должны быть обработаны вместе, но на входе они поступают в случайном порядке, а не упорядоченно по ключам. Поэтому данные привязанные к каждому ключу нужно читать из временного хранилища на жестком диске.

Использование SSD здесь врятли реально - у SSD маленький объем, короткое в таких условиях время жизни и высокая цена.

miksoftmihail_13Опечаточка вышла: 4TbЭто точно не нужно совать в MySQL.
Размер практически на пределе возможного - http://dev.mysql.com/doc/refman/5.5/en/table-size-limit.html
Это как раз не проблема, 4Tb можно положить в файл, а в mysql сохранить лишь адреса начал записей в файле.

miksoftmihail_13Это как раз не проблема, 4Tb можно положить в файл, а в mysql сохранить лишь адреса начал записей в файле.Тогда вообще не вижу смысла в СУБД.
Храните в отдельных файлах в файловой системе. Путь и имя файла - ключ.
20 млн файлов? Файловая система не база данных - она начинает тормозить еще хуже.

miksoftmihail_1320 млн файлов? Файловая система не база данных - она начинает тормозить еще хуже.С чего бы? Вы пробовали?
С учетом оговорки - "не валить все в один каталог, а создать разумной глубины дерево".
Файловая система, включая ее оглавление, вполне себе кэшируется операционной системой, так что особых проблем на этом пути я не вижу.
Зато не придется читать/писать содержимое файла, если его придется переместить в иерархии в другое место. Например, в каталог для обработанных файлов.
Вообще-то пробовал - грустная была картина.
А в одной дирректории или в разных не сильно принципиально. (на скорость не повлияет)

Если не использовать базу, надо делать один файл на данные и файл на индексы и уметь строить и использовать эти индексы. Выигрыш не очевиден.