UNION

Довольно интересная ситуация. На этом форуме мне несколько раз говорили, что запросы в БД надо обьединять и по максимуму переваливать задачи на сторону БД.

Тогда как обьяснить следующее:

Это время запроса? А что хотели? Union довольно медлителен.
А померяйте время исполнения скрипта через microtime. Если разница та же - то таки поздравляю вас.


type>=21 and type<=26 не понятнее будет написать? Или type in (21,22,23,24,25,26).

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

(Отредактировано автором: 23 Ноября, 2010 - 22:58:18)

-----
PostgreSQL DBA

так я и мерял через (time() + microtime(1))
И цифры не меняются. Да, конечно, беда в том что у меня денвер, установленный на флешку (старую), на хостинге будет быстрее, но всеравно разница в полторы тысячи раз!
а с запросами к базе я уже боюсь эксперементировать, стараюсь их делать как можно приметивнее. Потому что половина примеров вообще нехочет работать(говорят mysql очень обрезан), остальное медлительно. У меня на эти запросы боязнь развилась.

Может UNION и медлителен, но почему он более медлителен чем 9 отдельных запросов? Зачем он тогда?

Интересно, почему сортировку по разному делаете?

почему по разному? В обоих случаях по `tsdate` DESC, только в запросе с UNION приходится сортировку ко всему запросу делать, потому что по отдельным вложеным ORDER не работает. А так надо каждый раз mysql_data_seek() делать и проверять все с помощью if($row[type] == $i).
Вот я и думаю, где его вообще использовать, этот UNION и зачем...

Fobius Приведенная вами реализации сортировки информаицонных полей полученных в результате совмещенной выборки в действительности отличается от предполагаемого изначального вариана - поскольку включает в себя генерацию отельного неименованного списка элементов с осществленем сортировки внутри него - вместо выполненя внутренней операции по индексированным компонентам

-----
Сделать можно все что угодно - нужно только старание, терпение и хороший поисковик
Безлимитный web-хостинг от 15 рублей за 40 МБ дискового пространства - http://ihost[dot]oks71[dot]ru/

А с чего это вдруг случилось, что то, что Вы написали в отдельных запросах и через UNION - это одно и тоже?

Если хотите тупо объединить запросы в один, используйте UNION ALL (надеюсь, разницу объяснять не нужно)

Это одно и тоже, только отсортировано поразному. Если UNION ALL, то еще +1.5-2сек. Страшные цифры.

беда...

(Отредактировано автором: 28 Ноября, 2010 - 18:27:54)

Разница в том, что UNION ALL не будет исключать из результата одинаковые строки, выбранные разными запросами объединения. При чем тут это?

Fobius Объединять запросы - конечно хорошо, но делать такую кучу юнионов - это лишнее. Вот чего действительно стоит избегать, так это однотипных запросов в цикле. Из лучше преобразовывать в один запрос.

А по поводу скорости выполнения - тут что-то действительно необъяснимое. Надо тоже поэксперементировать.

У меня, кстати, тоже была недавно проблема с таким удивительным поведением. Сводилась она к тому, что select * from (select * from tbl) t where t.field = 345 Работало по-разному на 2 версиях Mysql. На одном индекс по field использовался при выборке, на другом - нет. Пришлось удивиться и переписать запрос.

Champion

это риторический вопрос?

(так как именно из-за исключения _одинаковых_ строк время выполнения может увеличиться на несколько порядков)



ага, уж такое необъяснимое, прям "есть ли жизнь на марсе"



может проще было статистику обновить? в обоих случаях данные в таблицах были одинаковые?

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

Fobius


ого, я такого еще не слышал... откуда "дровишки"?

Никак не на несколько порядков. В худшем случае каждый следующий подходящий результат будет задерживаться на log[осн2](N). N - количество уже найденных записей.
Вообще конечно да, union all предпочтительнее, хотя судя по where и так не будет повторяющихся столбцов.

Ну расскажи-ка. Мне тоже интересно. Чем union 2 запросов отличается от выполнения их по очереди?
Кстати, Fobius, а без сортировок какая картина получается?

Абсолютно. И индексы были только что созданы в обоих серверах, так что смысла обновлять статистику большого не было. Индекс хороший, почти уникальный. Оптимизатору незачем было его игнорировать. Кроме того запрос просто select * from tbl where field = 345 индексом пользовался. А такие не хотели.

Champion


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

2) В зависимости от "разного" эта табличка может быть создана на HD

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


разница почти как между обычным селектом и селектом с группировкой



поверьте, серверу от этого ничуть не легче (он пока не проверит всеравно не поверит) :)


при отсутствии сортировки UNION ALL почти что ничем, серверу единственно придется проверить поля на соответствии типов, но это копейки,

про UNION же, мне кажется, я уже довольно подробно все объяснил


ИМХО, Вы тут слегка путаете: только что созданный индекс или давно и карраптнутый (к примеру) разницы не играет.
На основе статистики оптимизатор принимает решение использовать ему индекс или нет, например, если у оптимизатора собственное мнение, что Вы собираетесь выбрать процентов 15 из таблицы, то он отключит индекс, а вот это мнение оптимизатор строит на основе статистики

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

По Union / Union All я согласен, но в это теме я вот что вижу:
- 9 отдельный запросов, в каждом из которых есть сортировка и забирание первых 6 записей.
- Те же 9 запросов, только без сортировки, в которых просто берутся первые 6 записей, объединяются юнионом, потом один раз результат сортируется.

Или я в чем-то не прав? Откуда такая разница тут в скорости?

Champion

черт, глаз замылился, "слона то я и не приметил" :(


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

зы (из околонаучного шаманства): я бы в примере, для начала, попробывал заменить * на названия полей и убрать скобки вокруг селектов...
а вообще интересно было бы посмотреть план запроса



ИМХО, это не так, ИМХО, статистика при создании/удалении/перестроении индекса не обновляется