Как быстро обновить 1000 записей?

[kosm]

Ребят, дайте плиз дельный совет, как на практике решаются такие задачи?

1.Есть простая табличка с полями "наименование" и "наличие", записей порядка 20000.
2.Есть некий файл (CSV), с теми же двумя полями, который пользователь кладет на сервер через форму, записей порядка 1000.

Как  можно наиболее оптимально и быстро отметить то, что изменил пользователь в файле, который загрузил на сервер?

Первое что приходт на ум, это построчный UPDATE из файла CSV в цикле. Но это порядка 1000 записей, и даже если на запись по 1сек, что не так, то это уже приличное время, за которое апаа не успевает его выполнить и отваливается по тайм ауту

Второй вариант мне когда подсказал уважаемый Alexandr, теоретически выглядит красиво.
Данные из CSV файла загружаются во временную табличку LOAD, а потом UPDATE головной таблици по условию из временной.
Вопрос, делал ли кто уже подобное? На сколько это действительно быстро и реально ли вообще?

PS: В обоих случая для ускорения процесса можно иметь еще одно поле "дата изменения" и включаеть еще и его в условие.

Ваше мнение, уважаеиые специалисты?

[Z@]

Для вставки есть такая штука как расширенная вставка(когда в один запрос можно много записейдобавить), может для апдейта тоже есть. Хотя не уверен что это ускорит дело.

[kosm]

Z@
Что за расширенная вставка?
Если делать по строчно, то наверно думаю большой выгоды не будет. Тут именно большой прирост в скорости нужен, чтобы укладываться в 30 сек, ну или чуть по-больше, если удасться с хостингом договориться увеличить таймаут.

PS: Дасть ли чего разбиение по транзакциям? Ведь если я явно не указваю START TRANS, то он для каждой опирации делает COMMIT?

[kosm]

Поправочка ко второму варианту с временной таблицей.
Сейчас посмотрел спецификацию по команде UPDATE MySQL - похоже что с помощью ее не свести будет две таблицы Множественные таблице в этой конструкции стали поддерживаться только с 4-й версии MySQL, у меня же 3.23.41
Может конечно можно как нить извратиться, но пока не знаю как...

Давайте ребят, подключайтесь к обсуждению... Тема ведь наверно довольно злободневная и все борятся за скорость И навернякак уже кто-то на чем-то остановился?

PS: Еще вариант, который останется, если ничего не найду, так это запуск скрипта локально по крону... и пущай себе там пыхтит по тихоньку.

[Alexandr]

По первому варианту (построчно): не думаю, что будет работать более 1-2 сек. (у меня используется этот вариант для обновления прайсов http://www.autodealer.ru/price/part/ - бегу по каждой строчке, чищу, вставляю), даже дома (на винде) не более 5 сек.

Второй вариант, более реален (конечно если надо вставить 1 в 1), ты его хоть попробуй....

kosm:
PS: В обоих случая для ускорения процесса можно иметь еще одно поле "дата изменения" и включаеть еще и его в условие.

Ваше мнение, уважаеиые специалисты?

Полный идиотизм

[Alexandr]

kosm:
у меня же 3.23.41

Делай так
REPLACE tbl SELECT * FROM tbl_for_up

[kosm]

Alexandr , рад видеть тебя!
По первому варианту: не совсем понял, у тебя весь процесс занимает 5 сек или одна строчка? Если строчка, то у меня примерно тоже, т.е. долго.

Второй вариант проверил - действительно быстро. На локальной машинке загрузка во временную табличку ~0,5 сек, а у хостера ~10сек, что вполне приемлемо.
Проверить перекачку по REPLACE как ты советовал на рабочей базе не получилось, т.к. я сам себя и всех окружающих ввел в заблуждение. Проблемма в том, что одна запись из CSV файла, может несколько раз фигурировать в записях БД (это я только сейчас выяснил, когда попытался сделать это поле UNIQUE, т.к. это обязательное требование для REPLACE).
Еще какие нить мысли есть?

[Alexandr]

kosm:
По первому варианту: не совсем понял, у тебя весь процесс занимает 5 сек или одна строчка?

Процесс:
1) юзер заливает файл (название детали, цена, валюта - разделитель таб.)
2) бегу по каждой строчке чищу название детали (трим, убираю лишние символы..., и т.д.), цену, валюту
3) для каждой строчки делаю инсерт в главную таблицу
Для ~5000 записей это ВСЁ занимает 1-2 сек. (у хостера на *nix\'e)
Кстати, основная таблица ~350000 записей....

kosm:
На локальной машинке загрузка во временную табличку ~0,5 сек, а у хостера ~10сек, что вполне приемлемо.

Ну и тормозной же хостер....

kosm:
Проблемма в том, что одна запись из CSV файла, может несколько раз фигурировать в записях БД (это я только сейчас выяснил, когда попытался сделать это поле UNIQUE, т.к. это обязательное требование для REPLACE).

kosm:
Есть простая табличка с полями "наименование" и "наличие", записей порядка 20000

Должна быть простая табличка с полями "id" (PRIMARY KEY), "наименование" и "наличие".
И такая табличка должна быть при любом варианте....
И CSV файл должен содержать id\'шники редактируемых строк.

[kosm]

Alexandr, хочу сразу извиниться - это я лоханулся
Только сейчас доперло, что индекса-то у меня по этому полю нет! Создал - стало работать на лок.машинке вместо 1.5-2 минут, 3 сек
Так что вопрос снимается - буду обрабатывать построчно.
Спасибо!