А тупой вариант написать кучу update через ; не прокатит вроде бы это будет как один запрос в БД?
UPDATE `table` SET `field`=1 where `id`=1;UPDATE `table` SET `field`=2 where `id`=2; ?
Насколько я осведомлён, запрос - это действие производимое с базой т.о. каждый UPDATE - считается запросом... и тут время так же тратится и на подключение к таблице...
я согласен что это не слишком эргономично... но других способов объединения запросов я не знаю... _________________
S|D|EG| Let's Rock! | XAP в ЛИЧКУ, SAPE
По моему самый лучший способ это сначала удалить изменяющиеся записи, а потом вставить их одним запросом insert.
Затраты на insert сведутся к построению индексов, затраты на delete это только поиск, update с case ИМХО будет значительно более затратным действием, во первых My-SQL будет вынужден работать с каждой строкой, а не менять их скопом, во-вторых беганье по case не самое лучшее занятие для SQL процессора + затраты на парсинг и подготовку большого CASE будут по моему мнению значительно больше, чем на стандартный insert.
P.S. lazutov сможете провести тест по перфомансу этих вариантов? _________________ Написание конвекторов, парсеров, интеграции нескольких сайтов (в личку)
у меня , к сожалению, такой перформанс на всех имеющихся машинах, что с этим лучше подождать.
На больших БД(мой случай) 1 UPD выполняется быстрее 2*(ins||del).
+ пои INSERT будет возникать фрагментация. на больших БД - потеря производительности в 2.5 раза.не тру.
Ладно, объясню ситуацию.
Есть база доменов RU. Скрипт берет и через команду host устанавливает IP. и так 70-95 раз в минуту(с учетом UPD).
Вот и получается,что UPD немного тормозит весь процесс. _________________ сервис DNS | разные http, DNS и прочие утилиты
Может завести несколько таблиц? Скажем для каждой итерации, т.е. берем данные из первой и инсертом записываем во вторую? Потом когда все домены будут перебраны, первую таблицу удаляем и используем новую? Да индекс строим во второй таблице только после добавления всех записей, инсерты можно объединять в один блок. _________________ Написание конвекторов, парсеров, интеграции нескольких сайтов (в личку)
итак. я решил сделать optimize table.
Смотрим лог.
Для нас важен последний параметр:EST(estimated)-время, затраченное на один ресурсоемкий запрос.(получить количество обработанных элементов)
Думаю,что не надо показывать пальцем в какой именно промежуток времени я оптимизировал таблицу
Таким образом. Имеем парадоксальнейшие результаты. Я не думал, что оптимизация таблицы ТАК сокращает временные затраты.
Резюмирую. Делать оптимизацию раз в 4 часа. _________________ сервис DNS | разные http, DNS и прочие утилиты