Андрей

LOAD DATA INFILE '/status2_50m.csv'
INTO TABLE compression_test.accounts_status50m
FIELDS TERMINATED BY ';' ESCAPED BY '\\'
LINES STARTING BY '' TERMINATED BY '\n'
IGNORE 1 LINES
(@col1,@col2,@col3) set account_id=@col1,service_id=@col2,status=@col3;

Думаю вполне понятный пример, в Вашей ситуации поможет добавление этой команды

(@col1,@col2,@col3) set account_id=@col1,service_id=@col2,status=@col3;

Посматриваю в строну noSQL, в частности - Хранилища колонок, а именно Apache Cassandra.
Но совсем не уверен что это будет правильным выбором. Смущает отсутствие возможности делать привычные выборки, и так же то, что данная СУБД рассчитана больше на постоянное добавление в неё данных чем на работу с существующими.
Я несколько в замешательстве. С одной стороны, в некоторых аспекта noSQL очень привлекателен. Но как делать на нем подобные выборки //Фильтр может быть вроде: выбрать все аккаунты с +(1) на определенных сервисах(при этом на сервисы есть доп фильтр - по hard-level и domain), + еще к этому всему надо будет прикрутить фильтр по датам, упустил из виду, но в целом сути это не меняет.
я слабо представляю. Как в принципе делать их на реляционных базах данных - понятнее.

Более подробное описание задачи(дубль из моего коммента выше):
"БД содержит в себе таблицы
accounts - в ней "столбцы" - ID(автоинкремент), email(varchar 255), password(varchar 255), login(varchar 255), и comment (TEXT). Для comment понимаю что нужно выносить в отдельную таблицу т.к. их будет
немного на общем фоне и это повысит производительность.
services - ID(автоинкремент), name (varchar 255), hard_level(tinyint), domain (varchar 255)
status - ID(автоинкремент), account_id(int 11), service_id(int 11), value(tinyint)

Как это все работает думаю понятно:
В таблицу accounts вносятся аккаунты.
В таблице services практически не меняются сервисы.
В таблице status при появлении информации вносится связка account_id - соответствующий ID аккаунта из acccounts, service_id - соответствующий ID сервиса, и значение 0/1. Для одного аккаунта может быть кол-во записей от нескольких, до полного кол-ва сервисов(160+)

Сейчас в базе есть 18млн тестовых записей в accounts, на основании которых я попробовал заполнить status. там начали получаться огромные значения ID, все лагает*. На реальном количестве аккаунтов 250млн+ - значения ID в таблице status станут просто огромными - грубо говоря что в районе 42500000000 - 12-значное число, что мне кажется соооовсем не здорово.

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

Фильтр может быть вроде: выбрать все аккаунты с +(1) на определенных сервисах(при этом на сервисы есть доп фильтр - по hard-level и domain), + еще к этому всему надо будет прикрутить фильтр по датам, упустил из виду, но в целом сути это не меняет.

*комп i7 3770, 8gb RAM, win7, установлен отдельно Apache и mySQL(не настраивал особо пока). сервер есть примерно такой же мощности, можно ставить любую ОС и делать что угодно. "
"