Как правильно обновлять прайсы в достаточно большой таблице?

[Labutin]

Как правильно обновлять прайсы в достаточно большой таблице?

Есть таблица sklad с полями:
Производитель: maker
Номенклатурный номер: number
Количество: quantity
Цена: price
ИдентификаторПоставщика: supplierID

Каждый поставщик имеет свой уникальный идентификатор (число от 0 и до бесконечности). Поставщики присылают прайс-листы с данными:
Производитель;Номенклатурный номер;Количество;Цена
Эти данные заносятся в указанную таблицу.
Чтобы обновить прайс поставщика происходит следующее:
DELETE FROM sklad WHERE supplierID='идентификатор обновляемого прайса';
и куча INSERT'ов в стиле:
INSERT INTO sklad (maker, number, quantity, price, supplierID) VALUES(........);
в одном INSERT указывается 100 VALUES, чтобы запрос был не вот уж безумно длинным.
Есть индексы по полям: maker, number, supplierID

Сейчас в таблице sklad 50 миллионов строк. Таблица InnoDB MySQL 5.0.77

При увеличении таблицы время обновления прайсов все расло и расло. Сейчас достигло уже неприемлемого времени.
1. Долго работает DELETE (при большом прайсе в районе 100 тыс позиций может удалять секунд 20-30)
2. INSERT'ы тоже работают не быстро - т.к. нужно индексы обновлять.

Сейчас все это закатал в одну транзакцию - стало раза в полтора - два быстрее. Остроту проблемы снял, но при увеличении базы снова все будет плохо.

Ну а теперь вопрос: может я в принципе что-то делаю не так? Если так, то как бы тут ускориться?

 

[fixxxer]

ну для начала replace

 

[Labutin]

думал в сторону replace
но нужно отслеживать те позиции, которые пропали из прайса. Как вариант, еще одно поле updateState
вместо delete делать
update sklad set updateState=1 where supplierID='идентификатор обновляемого прайса';
потом куча replace с updateState=0 и потом
DELETE FROM sklad WHERE supplierID='идентификатор обновляемого прайса' AND updateState=1;

так? это точно будет быстрее? По сути, replace наверняка внутри себя еще и аналог select'а вызывает? хотя как там внутри реализовано в mysql не в курсе...

 

[magic]

отключить ключи перед удалением/вставкой
использовать LOAD DATA INFILE
увеличить размер bulk_insert_buffer_size

 

[Labutin]

во время обновления прайсов поиск по базе должен работать быстро - это база на сайте
после включения ключей их обновление ведь тоже будет не быстрым?

 

[weregod]

Автор оригинала: Labutin
во время обновления прайсов поиск по базе должен работать быстро - это база на сайте
после включения ключей их обновление ведь тоже будет не быстрым?

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