| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Разница вызова запроса [D7]
alsov © (2007-08-17 17:05:00)Приветствую, Мастера
Скажите пожалуйста в чем разница вызова запросов с точки зрения производительности 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;
Заранее благоданет за ответы
Anatoly Podgoretsky (2007-08-26 17:38:00) [1]К диску вообще нет обращения, вся база в памяти, отдельные микросервесные обращения, типа записи об зеркалировании базы.
Диск и сеть простаивают.
Petr V. Abramov (2007-08-26 16:57:00) [2]> Anatoly Podgoretsky © (26.08.07 12:57) [25]
так диск, ИМХО, не успевает. смотри wait`ы (если в SQL оно возможно)
Anatoly Podgoretsky (2007-08-26 12:57:00) [3]Так и говорю, что отрабатывает.
Вот бы использование процессоров поднять до 100%, но это утопия.
Petr V. Abramov (2007-08-25 22:49:00) [4]> Anatoly Podgoretsky © (25.08.07 22:38) [23]
ну может после сбора какая-то статистика перешагнула некий порог, и оптимайзер перешел к нормальному плану (соломинка, которая переломила хребет верблюду :)
всяко бывает
Anatoly Podgoretsky (2007-08-25 22:38:00) [5]10 минут не на разбор, на разбор несколько секунд, это время работы запроса. Сервер у меня достаточно мощный.
Нагрузка на процессоры 25% - 4 процессора XEON - можно сказать что запрос плохо распаралеривается. всего на 25% нагрузки на каждый процессор.
Petr V. Abramov (2007-08-25 22:36:00) [6]ну 10 мин на разбор - это круто :)
Anatoly Podgoretsky (2007-08-25 22:35:00) [7]> Petr V. Abramov (25.08.2007 22:28:20) [20]
Размер стабильный, добавлений мало, но это не одна таблица а много и условий сотни.
Я профайлером поймал запрос, так устал ждать когда он прокрутится, а результатом одна страница отчета. Чистая аналитика.
Кроме того я первый раз выполнял в конце дня, а следующий раз рано утром, можно считать, что база не изменялась. Эксперимент был чистый, выполнялся только этот запрос, другой работы в это время не было.
В начале следующего месяца проверю, к этому времени в кеше запроса уже не будет.
Petr V. Abramov (2007-08-25 22:28:00) [8]> на следующий день уменьшается раза в два.
а каково относительноеизменение размера таблицы за день? или ее размер непредсказуем, массированные инсерты и делиты постоянно?
Anatoly Podgoretsky (2007-08-25 22:16:00) [9]Я вижу влияние статистики, по времени выполнения запросов, время выполнения на следующий день уменьшается раза в два. Есть у моих экономистов дурные запросы.
Если в первый день/дни время было 20 минут, то теперь оно уменьшилось до 10 минут. Прогресс налицо. Между запросами прошли сутки. Есть другое объяснение?
В следующий раз буду проверять в начале следующего месяца и посмотрю, что изменится - месяц это интервал выполнения запросов. Данный запрос выполняется несколько раз в день с одинаковыми данными. Предопределенный запрос. Таких запросов около 6 штук, мой конфигуратор поработает над алгоритмами, может сможет ускорить в несколько раз.
Petr V. Abramov (2007-08-25 22:03:00) [10]> Anatoly Podgoretsky © (25.08.07 21:42) [17]
тут дело не в статистике (она за день работы сильно не съедет, если ничего глобально не загружать/не читить)
дело в том, что сегодня запрос за день попросят, а завтра за год.
Anatoly Podgoretsky (2007-08-25 21:42:00) [11]> Petr V. Abramov (25.08.2007 20:11:16) [16]
Тут уже зависит от базы.
У меня статистика пересчитывается один раз в сутки, автоматический пересчет запрещен.
Petr V. Abramov (2007-08-25 20:11:00) [12]> 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 18:46:00) [13]Падает производительность сервера.
А не увлекаться не получится, каждый запрос обязан быть перекомпилирован, если это не сделать ранее
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 18:31:00) [14]> Anatoly Podgoretsky © (25.08.07 14:10) [13]
оно конечно так, только иногда лучше перекомпилировать. Если этим не увлекаться
Anatoly Podgoretsky (2007-08-25 14:10:00) [15]> sniknik (25.08.2007 13:44:12) [12]
Я думаю, что тоже самое - компиляция запросов и помещение их в кеш.
Отсюда все вытекающие - выталкивание из кеша ранее откомпилированых запросов и постноянна компиляция новых, не параметризированых и новое постороение плана.
sniknik (2007-08-25 13:44:00) [16]Anatoly Podgoretsky © (25.08.07 12:49) [11]
осторожнее... обсуждается оракл а не mssql, а какие у него "завихи" это тем кто с ним работает лучше знать.
то что они есть уверен (хватило личного опыта кратких с ним знакомств).
;)
Anatoly Podgoretsky (2007-08-25 12:49:00) [17]Не 95% а 100%, ну может за исключением тех серверов, где отсутствует план исполнения и компиляция запросов.
Petr V. Abramov (2007-08-24 23:17:00) [18]ессно, использование параметров в 95% случаев - best practice, но я-то хочу донести, что если вдруг непарметризованный запрос окажется хуже, надо не глаза лупить, а спокойно разбираться
Petr V. Abramov (2007-08-24 23:15:00) [19]> Дядька Кайт аж три книжки написал про то, как хорошо и правильно
а он написал, КОГДА хорошо и КОГДА правильно?
то, что дядька умный - сомнений нет, но все писатели с бодуна иногда бывают
> Desdechado © (19.08.07 17:16) [5]
> Не на худшее, а на среднее.
между NL и hash выбор в пользу hash, так что считай, что на худшее
KSergey (2007-08-20 16:44:00) [20]> Игорь Шевченко © (20.08.07 14:06) [6]
> Дядька Кайт аж три книжки написал про то, как хорошо и правильно
> использовать параметры в запросах...
Графоман, что с него взять.
| |
Страницы: 