11.10.2007 13:10
Pyatak
 
Ниже представлены два запроса, с помощью которых можно получить абсолютно одинаковые данные.
Вопрос: Какой из запросов должен выполняться быстрей?

Запрос 1:
Код:
SELECT c.article as "Артикул",
       cc.tree as "Код группы",
       cc.name as "Группа",
       c.name as "Наименование",
       vol.propval as "Емкость"

  FROM supermag.smcard c,
       supermag.sacardclass cc,
       supermag.smcardproperties vol

 WHERE c.idclass=cc.id
   AND c.accepted = 1
   AND c.article=vol.article(+)
   AND 'Volume'=vol.propid(+)
   AND cc.tree LIKE ('1.%')
Запрос 2:
Код:
SELECT c.article as "Артикул",
       cc.tree as "Код группы",
       cc.name as "Группа",
       c.name as "Наименование",
       vol.propval as "Емкость"

  FROM supermag.smcard c,
       supermag.sacardclass cc,
       (
        SELECT *
          FROM supermag.smcardproperties
         WHERE propid='Volume'
       ) vol

 WHERE c.idclass=cc.id
   AND c.accepted = 1
   AND c.article=vol.article(+)
   AND cc.tree LIKE ('1.%')
11.10.2007 13:35
akonev
 
идиотский вопрос: а что мешает просто прогнать и посмотреть?
первый у меня на тестовой базе выполняется за 8.328 секунд.
второй за 6.796 секунд.

у тебя может получиться и наоборот )))

похоже, что отчет по алкоголю рисуешь?
тебе не пофигу, эта разница в полтора раза? не каждый день он нужен будет.
11.10.2007 14:46
Pyatak
 
Ну почему сразу идиотский?
Вопервых, на моей базе эти запросы выполняются за 0.21~0.37 секунды и каждый раз по разному, то первый быстрей, то второй.

Вовторых, это в данном случае десятой секундой меньше, десятой секундой больше, меня же интересует принципиальный момент, какой из запросов выполнится быстрей при прочих равных условиях. А если в "запросе 2" в подзапросе будут миллионы строк, а потом из этих миллионов будут отобраны только 10 тех, артикулы которых есть в группе "1."? Какова разница во времени будет в этом случае? Я не знаю по каким принципам оракл будет обрабатывать данные, соответственно не могу сделать выводы о скорости, вот и интересуюсь у более грамотных и опытных товарищей))

Отчет по алкоголю уже давно нарисован, сейчас оптимизацией его занимаюсь, уж больно много девченки времени на него тратят. Уже удалось добиться успехов, но хотелось бы довести до идеала, видимо из спортивного интереса.
11.10.2007 15:29
OlegON
 
Такие вещи без планов запросов не обсуждаются обычно. Некогда его делать. Но навскидку я бы предпочел первый.
11.10.2007 16:05
akonev
 
прямо миллионы? ты реально столько карточек ожидаешь?
или переживаешь, что свойств много будет? привинтишь индекс по propid

кстати, по article+propid уже имеется. тык что оставляй первый и не мучай голову :)

а что время разное - от нагрузки зависит и того, что в кэше зависает.
будешь монопольно на базе гонять - будет практически стабильное время при последовательных запусках одного запроса (не считая первого запуска, конечно).
11.10.2007 16:37
Pyatak
 
Повторюсь, я в принципе спрашиваю, есть ли разница. Не надо привязываться к этому конкретному запросу, я его просто для примера привел. Подзапросом могут быть и не свойства, а строки документов, например, вот там точно миллионы.
12.10.2007 03:06
isi
 
olegon правильно говорит, нужны планы, а так гадание на кофейной гуще, да и не факт что он будет одинаково исполняться на тысячах записей и на миллионах.
12.10.2007 07:37
akonev
 
Цитата:
Pyatak Повторюсь, я в принципе спрашиваю, есть ли разница. Не надо привязываться к этому конкретному запросу
А без привязки не получится. Бывают случаи, когда глядя на запрос можно сразу сказать: тут будет фуллскан, это тормоз.
Но у тебя не получится навскидку сказать: вот такой вариант будет 100% быстрее.
Ты хочешь тонкой настройки запросов. Она возможна только на конкретных данных и с конкретными параметрами базы вообще и оптимизатора, в частности. С учетом наличия индексов.

По конкретной базе построятся какие-то конкретные планы выполнения запросов. Вот глядя на них уже можно что-то думать.
Часовой пояс GMT +3, время: 20:23.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.