Сортировка пользователей, оптимизация запросов « PHP для идиотов

Сообщения: 510 Репутация: N Группа: Джедаи

10 января 2010 г. 16:48, спустя 1 минуту 5 секунд

вот. я не знаю как сделать иначе. не знаю тонкостей

В первом посте код на отвлечённую тему. Вариант, предложенный artoodetoo, наверное, будет самым простым для реализации. Пробуй!

artoodetoo

Сообщения: 5147 Репутация: N Группа: в ухо

10 января 2010 г. 19:13, спустя 2 часа 24 минуты 41 секунду

SELECT * FROM `commands` WHERE `parent_id` = '{$parent_id}' ORDER BY id DESC LIMIT 10

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

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

ιιlllιlllι унц-унц

pasha

Сообщения: 1048 Репутация: N Группа: Адекваты

10 января 2010 г. 17:09, спустя 21 час 56 минут 26 секунд

добавь сюда номера по порядку и это твой случай. или нет?

не понял)

phpdude

Сообщения: 26646 Репутация: N Группа: в ухо

10 января 2010 г. 17:37, спустя 27 минут 29 секунд

artoodetoo, прости, но про unbuffered ты бред написал …

Спустя 191 сек.

~~сиськи~~ буфера mysql тут вообще не причем это раз.
2. что апдейты и инсерты можно и иногда стоит им делать когда не хочешь ждать ВЫПОЛНЕНИЯ ЗАПРОСА
3. придумано это для того, чтобы можно было начинать работать с данными ПО МЕРЕ ИХ ПОСТУПЛЕНИЯ, а не когда они все пришли и забуферизированы :)
4. помогает избежать out of memory exception при обработке больших статистик. так как память выделяется порциями, а не под все данные для рассчетов сразу.

зы: не пижжу ни слова, работал с этой штукой года 3+ назад. как раз статистику обсчитывал

Спустя 130 сек.

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

Сапожник без сапог

artoodetoo

Сообщения: 5147 Репутация: N Группа: в ухо

10 января 2010 г. 17:47, спустя 10 минут 13 секунд

artoodetoo, прости, но про unbuffered ты бред написал …
Спустя 191 сек.
~~сиськи~~ буфера mysql тут вообще не причем это раз.
2. что апдейты и инсерты можно и иногда стоит им делать когда не хочешь ждать ВЫПОЛНЕНИЯ ЗАПРОСА
3. придумано это для того, чтобы можно было начинать работать с данными ПО МЕРЕ ИХ ПОСТУПЛЕНИЯ, а не когда они все пришли и забуферизированы :)
4. помогает избежать out of memory exception при обработке больших статистик. так как память выделяется порциями, а не под все данные для рассчетов сразу.

зы: не пижжу ни слова, работал с этой штукой года 3+ назад. как раз статистику обсчитывал

- буфера при том, что обычно mysql клиент выбирает ВЕСЬ запрос в буфер и затем отдает его по мере вызова fetch. для unbuffered это не работает.
- может быть я был неправ насчет insert|update щас пойду проверять
- в случае slelect о каком поступлении речь? сначала строится план запроса, затем движок БД выцепляет данные, если надо создает временные таблицы и начинает выдавать результирующие записи по одной. в случае с буферами клиентская часть забирает их все и освобождает ресурсы сервера.
в случае unbuffered клиент получает очередную запись только при вызове fetch. сервер держит заблокированными ресурсы пока клиент не заберет все записи по очереди или не покончит самоубийством
- я и писал - экономия памяти (на клиентской стороне)

Спустя 169 сек.

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

ιιlllιlllι унц-унц

phpdude

Сообщения: 26646 Репутация: N Группа: в ухо

10 января 2010 г. 17:52, спустя 4 минуты 39 секунд

This saves a considerable amount of memory with SQL queries that produce large result sets, and you can start working on the result set immediately after the first row has been retrieved as you don't have to wait until the complete SQL query has been performed

- буфера при том, что обычно mysql клиент выбирает ВЕСЬ запрос в буфер и затем отдает его по мере вызова fetch. для unbuffered это не работает.

выше ты не писал что клиент. вот я и доебался, думал ты про сервер. кстати анбуфер работает АБСОЛЮТНО также как и обычный квери за условием, что fetch тебе как ты сказал при обычном из кеша клиента(mysql.so) отдает, а при небуфереде кеш тот тоже есть, но он содержит записи по мере получения их от сервера. если юзать fetch при анбуфере, то просто "можешь подождать получения следующей строки" если бд сервер отдает медленнее чем на пхп ты их обрабатываешь.

- может быть я был неправ насчет insert|update щас пойду проверять

отпишись, а то сам убегу) тоже 100% не знаю, только думаю. хочется знать можно ли на это рассчитывать в будущем, полезная опция была бы для всяких "счетчиков"

- в случае slelect о каком поступлении речь? сначала строится план запроса, затем движок БД выцепляет данные, если надо создает временные таблицы и начинает выдавать результирующие записи по одной. в случае с буферами клиентская часть забирает их все и освобождает ресурсы сервера.

и без буферов выцепляет сразу, думаешь выцепляние происходит при fetch? нет, конечно. абсолютно также выполнение происходит, только у тебя пхпшный "лок" снимается сразу после поступления ПЕРВОЙ строки результатов, а не ВСЕХ, вот и вся разница.

в случае unbuffered клиент получает очередную запись только при вызове fetch. сервер держит заблокированными ресурсы пока клиент не заберет все записи по очереди или не покончит самоубийством

ответил выше что чушь :)

- я и писал - экономия памяти

солидарен

Сапожник без сапог

artoodetoo

Сообщения: 5147 Репутация: N Группа: в ухо

10 января 2010 г. 17:53, спустя 1 минуту 38 секунд

http://ru.php.net/manual/en/function.mysql-unbuffered-query.php

you can start working on the result set immediately after the first row has been retrieved as you don't have to wait until the complete SQL query has been performed

я так перевожу: мы можем сразу начинать работать С ПЕРВОЙ ПОЛУЧЕННОЙ ЗАПИСЬЮ. никакого отношения к insert и update этот текст не имеет.
для insert|update возвращается всего одна запись о результате, так что ждать один хуй придется

ιιlllιlllι унц-унц

phpdude

Сообщения: 26646 Репутация: N Группа: в ухо

10 января 2010 г. 17:55, спустя 1 минуту 57 секунд

для insert|update возвращается всего одна запись о результате, так что ждать один хуй придется

не факт … протестировать бы :)

в пхп много интересных моментов)

Сапожник без сапог

artoodetoo

Сообщения: 5147 Репутация: N Группа: в ухо

10 января 2010 г. 18:06, спустя 10 минут 41 секунду

я не копал именно mysql но приходилось писать свои драйвера БД других систем. в принципе все у всех одинаково. на обоих концах (физическое хранилище и клиентская сторона) работают менеджеры записей. между ними (на сервере) прячется более хитрая логика — план запроса. клиент всегда получает записи по одной. сервер всегда лочит некие ресурсы пока клиет не вычерпает данные или не оборвет соединение. иначе не будет целостности.

я могу поспорить на жопу моей бабушки: unbuffered запрос не даст тебе выполнить никаких запросов пока не завершится сам. по той причине, что он сам еще не отпустил сервер. ты обязан в своем скрипте сделать это как можно быстрее.
я думаю все-таки скрипт на php перебирает цикл медленнее, чем внутренние процедуры mysql-клиента. так что вопрос использовать или нет unbuffered сводится к одному: есть риск наебнуть переполнение памяти или нет. когда выбираем 10 Маш или 25 записей с форума такое практически невозможно.

ιιlllιlllι унц-унц

phpdude

Сообщения: 26646 Репутация: N Группа: в ухо

10 января 2010 г. 18:17, спустя 11 минут 29 секунд

так мускуль ВСЕГДА ОТДАЕТ ЗАПИСИ, другое дело что при квери ты можешь работать когда ВСЕ будут слиты с сервера, а анбуф сразу после 1ой, в этом у них разница, fetch НЕЗАБИРАЕТ с сервера запись, он ее как и раньше берет из кеша mysql.so на клиенте

Сапожник без сапог

artoodetoo

Сообщения: 5147 Репутация: N Группа: в ухо

10 января 2010 г. 18:57, спустя 39 минут 33 секунды

что ты называешь "работой"? :) пока не получишь все записи ты все-равно ничего не выведешь.

ιιlllιlllι унц-унц

artoodetoo

Сообщения: 5147 Репутация: N Группа: в ухо

10 января 2010 г. 19:41, спустя 43 минуты 38 секунд

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

как только случается другой запрос до выборки всех записей unbuffered, query_id предыдущего запроса становится невалидным, fetch возвращает FALSE и цикл тихо завершается. проблема решается либо заменой unbuffered на обычный query, либо предварительным циклом по выборке всех записей до генерирующего цикла, что одно и то же.

так я перестал себя дурачить этим "сразу начинать работать"

ιιlllιlllι унц-унц

phpdude

Сообщения: 26646 Репутация: N Группа: в ухо

10 января 2010 г. 21:03, спустя 1 час 22 минуты 43 секунды

artoodetoo, поучительный пример :)

Сапожник без сапог

pasha

Сообщения: 1048 Репутация: N Группа: Адекваты

11 января 2010 г. 0:11, спустя 3 часа 7 минут 34 секунды