Всем привет.
У меня такая задачка
Есть MySQL-таблица, в которой 1000 записей (строк), а возможно и более.
В каждой строке, есть несколько полей и одно из этих полей мне нужно изменить в каждой из 1000 строк.
Новое значение каждого поля уникально и зависит от внешних факторов.
Изменения делаются из php-скрипта.

Вопрос - как из php-скрипты изменить все 1000 строк, таким образом что бы не превысить каких-либо лимитов (например, на количество запросов к БД) и не положить сервер перегрузкой?

Пример выполнения такой задачи - когда в биллинге снимается абонентская плата (изменяется балланс большого кол-ва клиентов, причем у каждого клиента свой балланс и изменяется в соответствиии с тарифом который использует конкретно данный клиент и дополнительными услугами типа выделенных IP).

Так понимаю, не делать же 1000 раз update?
Посоветуйте, пожалуйста, как быть, а то всю ночь бьюсь...

Заранее огромное спасибо всем откликнувшимся.

Раз каждое изменение индивидуально, то значит Вам всё равно придется делать 1 апдейт на 1 строку.

Значит задача сводится к тому, что бы сделать это в несколько приемов.

Лично мы делали бы примерно так, если надо за раз не запускать 1000 запросов.
Что бы не апдейтить одно и то же по нескольку раз
1) В каждое поле добавить дату последнего изменения. Её апдейтить при изменении поля. Скрипт выбирает допустим 10 полей которые не обновлялись последними. Апдейтит их нужным образом.
Или
2) Завести еще одну таблицу (или файл) где хранить уникальный ID последней апдейтеной строки. И выбирать 10 следующих после нее. Записывать ID конечно после апдейта.
Запускать скрипт можно
а) По крону (например простым GET/wget).
б) Выводить после завершения простую хтмл страницу с meta refresh=Х секунд на самого себя.
Неплохой идеей может являться лок таблицы на время апдейта, если апдейт конечно не 30 минут занимает. Будет работать быстрее и безопаснее.
А вообще, Вы уверены что не хотите переписать эту задачу на файлы? Файл считали, что надо проапдейтили, и назад записали. Хотя работать с результатом конечно труднее будет, особенно на сложных операциях. но Вы же не уточнили что делаете с данными кроме апдейта

В биллингах идет так:
На каждый учетный период в отведенной под это дело таблице накапливается история операций.
Затем когда происходит переход - данные из таблицы консолидируются select'ом и переходят в итоговую таблицу.

А то что написано выше - это не биллинг а непонятно что...

Да кстати, прочитали сначала что надо сделать, а вот для чего - не обратили внимания.

Вот это в частности



Можно сделать проще, посмотрите математические функции для операций с БД. Можно апдейтнуть всё за 1 запрос, вычисляя сумму вычета на базе данных о тарифе и используемых услугах.
P.S.: А историю операций вести надо по любому, esupport полностью прав.

Большое спасибо ответившим



Вот это я и хотел узнать, что не существует варианта с единственным запросом, если каждое изменнение уникально и зависит от внешних факторов


Спасибо за советы, второй обязательно применю, если не перепишу базу таким образом, что бы не было внешних факторов.

Очень хотелось вынести это поле из базы в тестовый файл
Но помню очень бурный спор (не с Вами, но здесь, на форуме), где обсуждалось быстродействие MySQL против txt при одновременной работе с большим кол-вом данных...

Сложно к пониманию, но информация к размышлению, спасибо

То что написано выше - абстрактное рассуждение по поводу абстрактной проблемы



Это было бы идеально, если бы не:
Таблица clients содержит поле ballans а так же поле package_ID являющееся внешним ключем, а так же поле personal_discount (где в процентах указана персональная скидка).
Таблица packages содержит поле cost (стоимость, например суточная)
(естесственно обе эти таблицы содержат не только эти поля)
Пока еще можно проапдейтить одним запросом, типа UPDATE clients SET clients.ballans = clients.ballans-packages.cost WHERE clients.package_ID = packages.id
Ну образно конечно написал, но что-то в этом образе посторить можно
Мешает то, что есть еще дополнительные факторы, влияющие на сумму снимаемую с ballans каждой конкретной строки - это как personal_discount (персональная скидка), так и addons (например "дополнительные услуги") определяющие итоговую сумму снимаемую с ballans


В общем, пока писал-писал здесь пост, половину стрер, потому что вдруг понял, что модифицировать все записи одним запросом не нужно (не безопасно) - пришло понимание что и как сделать

edogs, спасибо за подсказку

Это очень дельная мысль

Всем спасибо

Холиварная тема, но смысл в целом сводится к тому, что если идут операции выборки, фильровки, сортировки, то лучше не мучаться и сделать на базе. Если же идут операции - взял всю информацию - обработал - положил обратно, то файл в целом рулит. Таблица в БД это на самом деле, такой же физический файл со всеми вытекающими.
Можно I) использовать вложенные запросы II) временные таблицы.

Хехе, года не прошло с того момента, как я спорил на форуме, доказывая что файловую БД местами использовать не менее удобно, чем MySQL и быстродействие не ниже. Причем тогда почти дословно повторил фразу


Меня тогда запинали, доаказывая что не стоит изобретать велосипед Но в целом велосипед действительно изобретать не стоит, лучше совершенствовать изобретенное.

У меня вопрос к edogs как к разработчикам и к eSupport.org.ua (и другим хостерам) как к тем, кто понимает что такое лимиты, потоки и т.п.

Исходя из задачи (обновить 1000 записей), что вы думаете о таком приеме:



В этом коде происходит буквально следующее - скрипт делает 10 запросов к БД и "засыпает" на 1 секунду. При этом процесс скрипта продолжает существовать и через секунду скрипт делает еще 10 запросов и снова засыпает. И так пока не выполнит все запросы.
На 1000 запросов потребуется меньше двух минут
Получается не более 10 зпросов к БД в секунду.
Сразу скажу, что лично мне в этом способе не нравится потеря совместимости с php safe_mode (функция set_time_limit), но...
Хочется поинтересоваться у eSupport.org.ua и вообще у хостеров - какова вероятность, что такой процесс будет остановлен из-за каких-либо лимитов (например на кол-во запросов к БД от одного процесса), ну и повторяюсь, хочется поинтересоваться у edogs как у разработчиков - что Вы думаете об этом способе, имеет ли он смысл?

1) set_time_limit устанавливает общее время скрипта на выполнение, не надо его в цикл. Пишите 1 раз в начале скрипта - столько времени - сколько надо. 0 - если хотите снять лимит.
2) sleep в таком смысле это имхо ужасно. Кстати, что интересно, проспавшая 1 секунда не влияет на п.1. Но слип оставляет висящим процесс (утрируем), и зачем это делать?
3) Вместо $s можно использовать $i%10
4) Если скрипт остановится неожиданно (ну сервер рестартовал), все заново? У Вас нет отметки о текущем статусе.
5) Способ такой нам очень не нравится по куче причин. 1000 запросов из скрипта. Слип. Неизвестное количество времени работы.
6) С нашей точки зрения А и Б варианты для повтора (крон или мета рефреш) являются намного более оптимальными. Получается просто аккуратный запуск скрипта. В варианте Б, для того, что бы не считывать каждый раз отметку последней записи, можно кидать рефреш с параметром (хотя запоминать все равно надо).
P.S.: Сорри за критику

Возможно стоило сразу уточнить несколько моментов.
1. Скрипт изначально запускается по крону (поэтому в принципе, скрипт может висеть хоть час, если сам по себе процесс не будет создавать нагрузки (в чем сильно сомневаюсь, ведь это всего-лишь навсего единственный процесс использующий несколько килобайт памяти)

2. Скрипт (запускаемый ежесуточно) обновляет те записи, где "дата последнего обновления" ниже текущей (по формуле: текущее значение - (вычитаемая сумма * (текущая дата - дата последнего обновления = дней)) т.е. если вдруг скрипт остановится, то в следующий раз он вычтет корректное значение).

3.
set_time_limit в цикле, потому что


4.

Что бы было не более десяти запросов к БД в секунду

Спасибо за критику


P.S. Внесенные мной дополнения никак не влияют на Ваше мнение относительно такого способа?
P.P.S. Хотя все равно я уже почти решил использовать для этого поля файл, потому что ту же совместимость с safe_mode терять не хочется

Теоретически может, а на практике, Вы же не знаете условий и лимитов сервера на котором он запускается, мы так поняли. На одном из хостеров, нам было интересно узнать, что процессы выполняющиеся дольше 10 минут прибиваются безоговорочно, из-за чего имели проблему с попыткой сдампить большую базу.
И по поводу нескольких килобайт памяти - не факт. Померяйте для интереса. memory_get_usage А зачем? Поставьте в начале на 0 и всё. Скрипт будет выполняться до завершения.
А лимиты могут быть разные
По сути нет. Ключевой момент тут в том, что мы не видим смысла находить способы искуственно затягивать выполнение скрипта и размазывать запросы в базу по времени, если есть вариант просто вызывать скрипт выполняющий малую работу почаще. Если бы была необходимость выполнить эту процедуру за 1 запуск скрипта, мы бы подумали над Вашим решением, но раз такой необходимости нет, то имхо надо упрощать.

Век живи - век учисль, спасибо