Разница вызова запроса

← →
alsov © (2007-08-17 17:05) [0]

Приветствую, Мастера

Скажите пожалуйста в чем разница вызова запросов с точки зрения производительности Oracle :

qry:=TADOQuery.Create(Self); qry.sql.add("select name, surname from user where user_id=123); qry.Open;

И второй вариант вызов через параметр

qry:=TADOQuery.Create(Self); qry.sql.add("select name, surname from user where user_id=:id); qry.ParamByName("id").value := 123; qry.Open;

Заранее благоданет за ответы

← →
stanislav © (2007-08-17 17:13) [1]

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

← →
Desdechado © (2007-08-17 17:13) [2]

Вот из моей статьи выдержка:
2.1.Использование параметрических запросов Использование параметров в запросах является правилом хорошего тона в программировании, поскольку имеет множество положительных аспектов: Улучшается читаемость и облегчается сопровождение кода программ. При циклических выполнениях запроса с разными значениями параметров есть возможность «подготовить» запрос на сервере один раз, после чего он выполняется быстрее без необходимости «подготовки» на каждой итерации. Исчезают ошибки, связанные с наличием апострофов, кавычек и неожиданных форматов даты внутри заданных пользователем текстовых строк в конструируемых «на лету» запросах. Запросы, «подготовленные» сервером, хранятся некоторое время в кэше. Параметрический запрос хорош в этом случае тем, что он подходит для любых значений параметров такого же запроса, тогда как непараметрический – только для точно такого же, включая заданные в его теле (а не в параметрах) значения. Поэтому при совпадении «подготовка» не проводится, что для параметрического запроса это случается гораздо чаще, чем для непараметрического. Непараметрические запросы тоже попадают в кэш, «выбивая» оттуда давно неиспользованные запросы (любого вида). Однако при большом потоке разнообразных запросов выбиваются и параметрические, которые имели шанс быть использованными далее, и заменяются непараметрическими, которые таких шансов не имеют. Это отрицательно сказывается на производительности сервера, т. к. ему приходится заново подготавливать параметрические запросы, уже «выбитые» из кэша.

← →
alsov © (2007-08-17 17:16) [3]

Спасибо

Все ясно

← →
Petr V. Abramov © (2007-08-18 13:19) [4]

> Desdechado © (17.08.07 17:13) [2]
> Параметрический запрос хорош в этом случае тем, что он подходит для любых значений параметров такого же запроса
подходит-то он подходит, но только по тексту, а кешируется еще и план.
А вот план для другого значения параметра может оказаться совсем неоптимальным.
К тому в версиях до 9-ки даже при первом построении плана оптимизатор НЕ ЗНАЕТ значение параметра и строит план исходя "с расчетом не худшее".

Но это не значит, что я ОТГОВАРИВАЮ использовать параметры, наоборот, использовать их чаще всего ХОРОШО.

← →
Desdechado © (2007-08-19 17:16) [5]

Petr V. Abramov © (18.08.07 13:19) [4]
Не на худшее, а на среднее. А механизм "подглядывания" значения в более позних версиях может быть и хуже, т.к. хороший план для "подглянутого" нетипичного значения может быть ужасным для всех последующих типичных.

← →
Игорь Шевченко © (2007-08-20 14:06) [6]

Дядька Кайт аж три книжки написал про то, как хорошо и правильно использовать параметры в запросах...

← →
Anatoly Podgoretsky © (2007-08-20 15:28) [7]

Точнее он написал, как нехорошо их не использовать, а также почему нельзя писать SELECT *

← →
KSergey © (2007-08-20 16:44) [8]

> Игорь Шевченко © (20.08.07 14:06) [6]
> Дядька Кайт аж три книжки написал про то, как хорошо и правильно
> использовать параметры в запросах...

Графоман, что с него взять.

← →
Petr V. Abramov © (2007-08-24 23:15) [9]

> Дядька Кайт аж три книжки написал про то, как хорошо и правильно
а он написал, КОГДА хорошо и КОГДА правильно?
то, что дядька умный - сомнений нет, но все писатели с бодуна иногда бывают

> Desdechado © (19.08.07 17:16) [5]
> Не на худшее, а на среднее.
между NL и hash выбор в пользу hash, так что считай, что на худшее

← →
Petr V. Abramov © (2007-08-24 23:17) [10]

ессно, использование параметров в 95% случаев - best practice, но я-то хочу донести, что если вдруг непарметризованный запрос окажется хуже, надо не глаза лупить, а спокойно разбираться

← →
Anatoly Podgoretsky © (2007-08-25 12:49) [11]

Не 95% а 100%, ну может за исключением тех серверов, где отсутствует план исполнения и компиляция запросов.

← →
sniknik © (2007-08-25 13:44) [12]

Anatoly Podgoretsky © (25.08.07 12:49) [11]
осторожнее... обсуждается оракл а не mssql, а какие у него "завихи" это тем кто с ним работает лучше знать.

то что они есть уверен (хватило личного опыта кратких с ним знакомств).
;)

← →
Anatoly Podgoretsky © (2007-08-25 14:10) [13]

> sniknik (25.08.2007 13:44:12) [12]

Я думаю, что тоже самое - компиляция запросов и помещение их в кеш.
Отсюда все вытекающие - выталкивание из кеша ранее откомпилированых запросов и постноянна компиляция новых, не параметризированых и новое постороение плана.

← →
Petr V. Abramov © (2007-08-25 18:31) [14]

> Anatoly Podgoretsky © (25.08.07 14:10) [13]
оно конечно так, только иногда лучше перекомпилировать. Если этим не увлекаться

← →
Anatoly Podgoretsky © (2007-08-25 18:46) [15]

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

select fld where fld=1 select fld where fld=2
Это два разных запроса, две компиляции, два построения плана

select fld where fld=:p
а это один какой бы р не был, ноль компиляций, кроме первого вызова и однократное построение плана в общем случае.

Запросов подобных первому типу будет много и они вытолкнут из кеша запросы второго типа, особено если они будут в более худшей форме, что не редкость, а именно такие
select * where fld=значение
Вот такие запросы почти всегда будут компилироваться, из-за звездочки
или по крайней мере сначала будут разворачиваться до
select fld1, fld2,... where fld=значение
Что займет еще больше времени, чем просто компиляция.

Если запросы первого типа делают из-за низкой квалификации, то запросы третьего типа делают уже из-за лени или лень + низкая квалификация

← →
Petr V. Abramov © (2007-08-25 20:11) [16]

> Anatoly Podgoretsky © (25.08.07 18:46) [15]
select f1, ... fn
from table1, ... bigtaBLE bt
where /* много всего */ and bt.somedate between :date1 and :date2
если этот отчет выполняется раз в день, то пусть лучше компилится,
чем на среднефиговом плане выполняется

> select fld where fld=1
> select fld where fld=2
ну это классика :)
еще скажи по fld первичный ключ :)

← →
Anatoly Podgoretsky © (2007-08-25 21:42) [17]

> Petr V. Abramov (25.08.2007 20:11:16) [16]

Тут уже зависит от базы.
У меня статистика пересчитывается один раз в сутки, автоматический пересчет запрещен.

← →
Petr V. Abramov © (2007-08-25 22:03) [18]

> Anatoly Podgoretsky © (25.08.07 21:42) [17]
тут дело не в статистике (она за день работы сильно не съедет, если ничего глобально не загружать/не читить)
дело в том, что сегодня запрос за день попросят, а завтра за год.

← →
Anatoly Podgoretsky © (2007-08-25 22:16) [19]

Я вижу влияние статистики, по времени выполнения запросов, время выполнения на следующий день уменьшается раза в два. Есть у моих экономистов дурные запросы.
Если в первый день/дни время было 20 минут, то теперь оно уменьшилось до 10 минут. Прогресс налицо. Между запросами прошли сутки. Есть другое объяснение?
В следующий раз буду проверять в начале следующего месяца и посмотрю, что изменится - месяц это интервал выполнения запросов. Данный запрос выполняется несколько раз в день с одинаковыми данными. Предопределенный запрос. Таких запросов около 6 штук, мой конфигуратор поработает над алгоритмами, может сможет ускорить в несколько раз.

> на следующий день уменьшается раза в два.
а каково относительное изменение размера таблицы за день? или ее размер непредсказуем, массированные инсерты и делиты постоянно?

> Petr V. Abramov (25.08.2007 22:28:20) [20]

Размер стабильный, добавлений мало, но это не одна таблица а много и условий сотни.
Я профайлером поймал запрос, так устал ждать когда он прокрутится, а результатом одна страница отчета. Чистая аналитика.
Кроме того я первый раз выполнял в конце дня, а следующий раз рано утром, можно считать, что база не изменялась. Эксперимент был чистый, выполнялся только этот запрос, другой работы в это время не было.
В начале следующего месяца проверю, к этому времени в кеше запроса уже не будет.

ну 10 мин на разбор - это круто :)

10 минут не на разбор, на разбор несколько секунд, это время работы запроса. Сервер у меня достаточно мощный.
Нагрузка на процессоры 25% - 4 процессора XEON - можно сказать что запрос плохо распаралеривается. всего на 25% нагрузки на каждый процессор.

> Anatoly Podgoretsky © (25.08.07 22:38) [23]
ну может после сбора какая-то статистика перешагнула некий порог, и оптимайзер перешел к нормальному плану (соломинка, которая переломила хребет верблюду :)
всяко бывает

Так и говорю, что отрабатывает.
Вот бы использование процессоров поднять до 100%, но это утопия.

К диску вообще нет обращения, вся база в памяти, отдельные микросервесные обращения, типа записи об зеркалировании базы.
Диск и сеть простаивают.

Разница вызова запроса Найти похожие ветки