Последнее время авторы разных модулей, а так же оптимизаторы Нюки серьезно взялись за дело. Именно оптимизаторам адресована эта крошечная заметка. А появилась она именно из-за того, что мы задумались об оптимизации некоторых своих модулей. Не то что бы это было нам необходимо, но, как бы модно
Началось всё с того, что мы решили
1) заменить в коде запрос типа select * from bla bla bla и последующую группу циклов отбора значений на один запрос в БД.
2) Заменить в коде несколько запросов в разные БД на один хитрый select с кучей OR и JOIN команд.
И то и другое сделали. Потом на минутку задумались, посмотрели на скорость выполнения нюковских скриптов. Задумались над увиденным результатом.
Несмотря на то, что в 1-ом случае после селекта куча циклов выполняла работу, быстрее выполнялся "тупой" селект с циклами, чем один "умный" селект. в 2-ом случае. После замены 4 селектов подряд на один но сложный, количество запросов в БД уменьшилось.
НО в обоих случаях время исполнения !увеличилось!.
Заметим, всё это тестировалось на локалхосте изначально.
Для чистоты эксперементы мы вынесли эти куски кода в отдельный скрипт. Использовали функцию microtime() для подсчета времени выполнения. Использовали 1000 кратный прокрут в цикле для уменьшения погрешности.
Попробовали проделать это у себя на локалхосте, у себя на хостер, и ещё на одном хостере. Получили РАЗНЫЕ результаты. Где-то ускорение, где-то замедление.
Сделали ещё несколько простейших тестов. В основном замена двух простых запросов селект, на один сложный. Опять же РАЗНЫЕ результаты. Опять же где-то замедление, а где-то ускорение.
Наш вывод:
1) Очевидно, что лишний запрос в БД увеличивает время выполнения скрипта, за счет лишних запросов в БД
2) Так же очевидно, что усложнение запроса в БД увеличивает время выборки результата из БД, особенно если он достаточно сложный.
3) Утверждение, что селект выбирает быстрее чем цикл из результатов по селекту написанный на php - весьма спорно.
4) Два простых селекта подряд очень часто быстрее одного сложного.
5) Очень многое зависит от хостера. От загруженности БД. От загруженности проца ответственного за выполнение скрипта. От того разные ли сервера ведут БД и "остальное". От количества памяти установленной там и там.
P.S.: К определенным выводам мы не пришли. Но очевидно что оптимизаторы выполняют правильную работу. Однако следует обратить внимание на то, что не все типы оптимизации приводят к ускорению.
-------------------------------------------------------------------------------- Не удержался и решил так же высказаться на данную тему.
В последнее время пошла своеобразная гонка, уменьшить количество запросов до минимума. В принципе идея правильная, но только в том случае когда Вы уменьшаете (убираете) не нужные запросы, те которые в системе не используются или практически не приносят никакой пользы (внутренняя статистика, реферальные ссылки, вывод блоков пользователей и т.д.). Я полностью согласен с автором данной статьи, от того что вы два запроса объедените в один, скорость выполнения запроса и нагрузка на сервер не уменьшится (а в отдельных случаях может существенно увеличиться)! Посудите сами откуда ей уменьшаться если этот один запрос выполняет те же самые действия что и два отдельных запроса?!
Дело не в количестве запросов а в их необходимости и корректности.
По поводу необходимости мне кажется и так все понятно, тут каждый решает для себя сам, а вот по поводу корректности, в PHP-Nuke до сих пор проблемы.
Взять хотя бы такой пример, как два вида коннекта к базе. В системе до сих пор применяются коннекты на основе $db и $dbi а зачастую эти два вида используются в одних функциях! Часто встречаются функции с выборкой всех данных в таблице (*) когда на самом деле нужны данные только с одного столбца и т.д.
В общем подведя итог могу сказать что оптимизация это хорошо, но только в том случае когда делается она именно ради оптимизации а не ради уменьшения любым способом количества запросов. Все это напоминает ситуацию с применением классов при написании программ на PHP. Раньше считалось что применение классов свидетельсто мастерства программиста, и вот начали пихать эти самые классы всюду куда только можно, нисколько не задумываясь о том а нужны ли они в данной ситуации вообще. Следствием такого проявления профессионализма стали невероятно "тяжелые скрипты". И вот в данном случае часто слышится нечто подобное. Я объеденил 3 запроса в один! Молодец, что ты научился объеденять запросы, но хочется спросить, а уверен что это объединение действительно уменьшило нагрузку на систему а не привело к противоположному результату?!
я, наверное, скажу глупось и не к месту, но: в рамках несложных скриптов для ранцмс с бд никогда не было проблем, но как только пришлось писать нечто сложное с огромным количеством данных и отн. сложной выборкой, прблемы сразу появились. При использовании mssql и access'a при большом кол-ве запросов с несложной выборкой либо падал сервер (сообщал, что кончилась память или зависал), либо просто некоторые запросы не обрабатывались, причём от того, сколько процессоров и памяти было на сервере (pm1,6/512 и 2x что-то там/2g), время правильной жизни проги зависело явно не пропорционально - различия были невелики. Усложнение же запросов и сведение их кол-ва к минимуму решило проблему. Вывод, который я для себя сделал - жестокая оптимизация запросов в некоторых местах необходима. В тех же, где можно обойтись и без неё, лучше не усложнять себе жизнь.