Комментарии: Массовый UPDATE в MySQL

Автор: Драйв

Драйв — Fri, 19 Mar 2010 04:29:10 +0000

Хорошая статья. Действительно было интересно почитать. Не часто такое и встречается та.Наверное стоит подписаться на ваше RSS

Автор: Nayjest

Nayjest — Tue, 01 Dec 2009 23:28:50 +0000

хм, интересно конечно. Еще интереснее было бы потестить на больших таблицах, действительно ли это быстрее, ведь это в значительной части зависит от реализации движка БД

Автор: Александр

Александр — Tue, 01 Dec 2009 11:36:10 +0000

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

Автор: Александр

Александр — Tue, 01 Dec 2009 11:30:36 +0000

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

Автор: CharnaD

CharnaD — Tue, 01 Dec 2009 11:07:10 +0000

Ну если так, то да.

Автор: Александр

Александр — Tue, 01 Dec 2009 10:49:17 +0000

да, можно и так, но давно я писал код, который собирает все разделы в один массив, и через рекурсию суммирует кол-во записей всех потомков, для этого лишние запросы не нужны, после суммирования, остаётся обновить счётчик(кол-во записей) только родителей, а вот ссылка на тот самый мой код
http://narod.ru/disk/15328134000/_update_count.php.html

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

Автор: CharnaD

CharnaD — Tue, 01 Dec 2009 10:37:07 +0000

Александр, в вашем случае я бы оставил вариант «UPDATE cats SET cats.cat_counter = ( SELECT COUNT(*) FROM items WHERE items.cat_id=cats.cat_id )». Потому что, чтобы собрать все данные, вам все равно придется сделать N запросов для подсчета, по количеству категорий. И вам все равно придется обновить каждую строчку таблицы. Так что использовать временную таблицу, я думаю ни к чему.

Автор: Александр

Александр — Tue, 01 Dec 2009 10:19:32 +0000

хм, интересно, спасибо за идею, надо будет по пробовать. Хотелось ещё дополнительно сократить кол-во запросов перерасчёте кол-во записей у родителей. Я рассказывать не буду, а просто сообщюу ссылку на одну из-за меток автора, про синхронизацию разделов
http://kurilka.co.ua/archives/sync_counter_mysql/

первый запрос что там приводится, делает пересчёт кол-во записей у каждого раздела, остаётся сделать обновление только родителей, но их может быть порядком, ровно столь коже и запросов, если родителей обновить по вашему примеру, создаём отдельную таблицу, в ней сохраняем кол-во записей уже подсчитанные, а далее обновляем в родной таблице, таким образом, у нас будет 2-3 максимум запроса, при этом кол-во разделов может иметь не ограниченное вложенность разделов, что очень даже не плохо.

Спасибо вам

Автор: Snowcore

Snowcore — Tue, 01 Dec 2009 10:10:46 +0000

Прикольно, надо будет попробовать!

Автор: CharnaD

CharnaD — Tue, 01 Dec 2009 10:07:29 +0000

Да. Скажем у нас 500 записей. 1 запрос будет выполняться значительно быстрее, чем 500 запросов, даже если этот один будет очень длинный.

При таком комбинированном INSERT будет 1 запрос.

Автор: Александр

Александр — Tue, 01 Dec 2009 04:45:21 +0000

извиняюсь, что это даёт? увеличится производительность такого метода сохранения?

да и при выполнении:

INSERT INTO ids VALUES
(0, ‘http://url1.ru‘),
(0, ‘http://url2.ru‘),
(0, ‘http://url3.ru‘);

сколько запросов 1 или 3 будет?