Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2004.05.02;
Скачать: CL | DM;

Вниз

Время выполнения процедуры   Найти похожие ветки 

 
wild_arg ©   (2004-04-05 15:44) [0]

Народ может кто сталкивался?
Написал SQL-код процедуры в Query Analyzer. Все отдладил. Параметры процедуры задал переменными. Все выполняется 12 сек.
Делаю такую процедуру, запускаю ее - она выполняется больше минуты.
В коде ничего не менял - почему такая разница во времени выполнения


 
Ega23 ©   (2004-04-05 15:50) [1]

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

А как ты до этого её запускал? Из QA? Когда 12 секунд выполнялось?


 
Desdechado ©   (2004-04-05 15:54) [2]

прикол может быть в том, что в QA данные до конца не фетчаться
фетч может много времени занять


 
Ega23 ©   (2004-04-05 16:25) [3]

прикол может быть в том, что в QA данные до конца не фетчаться
фетч может много времени занять

Это в смысле?


 
sniknik ©   (2004-04-05 16:34) [4]

у него серверный курсор стоит, данные(первые) показываются сразу после выполнения запроса дальше фетчатся в бакграунде до конца выборки.
у тебя (при клиентском курсоре) ждет самого последнего байта выборки(запрос+передача) а после отображается.


 
Ega23 ©   (2004-04-05 16:35) [5]

А, в этом смысле...


 
wild_arg ©   (2004-04-05 16:43) [6]

Народ, решил проблему! :)
Оказалось, я где-то нашел такую хрень, по разному план выполнения строится:
привожу как понял. рассмотрим два примера:
1.
declare @date datetime
set @date = "2004-03-01"
select * from Заявки where date>=@date

2.
select * from Заявки where date>="2004-03-01"

если у нас по полю Date построен индекс, то он будет задействован только во втором случае. в первом, как написано было, оптимизатор не знает чего мы там будем искать и индексом не пользуется.
Вот такая хрень.
Оформим этот код в процедуру:

create procedure Proc
        @date datetime
as
select * from Заявки where date>=@date

Когда мы вызовем ее в анализаторе: Exec Proc "2004-03-01", то оптимизатор на входе после замены в тексте параметров на значения, получит код приведенный в примере 2 и при оптимизации воспользуется индексом.

А у меня в задаче кривые индексы (ну база не моя, убивать я их не стал). И вот какая хрень вышла, что написав код наподобе примера 1., оптимизатор не юзает индекс и выполняет запрос быстрее, а оформляем процедуру и все, хана, пошла работа над индексом. НО! :) я обманул его, написал процедуру таким образом:

create procedure Proc
        @_date datetime
as
declare @date datetime
set @date = @_date
select * from Заявки where date>=@date

и оптимизатор, получает код похожий на пример 1. и индекс не юзает :)
Но, наверное, можно просто как-то отключить использование индексов? Типа set useindex off или что-то в этом роде. Не знаете как?


 
wild_arg ©   (2004-04-05 16:48) [7]

это все тут
http://www.osp.ru/win2000/sql/dialogs/311_1_print.htm


 
ZrenBy ©   (2004-04-05 16:54) [8]

Можно указать принудительное сканирование таблицы с помощью
WITH(INDEX=0)



Страницы: 1 вся ветка

Текущий архив: 2004.05.02;
Скачать: CL | DM;

Наверх




Память: 0.49 MB
Время: 0.022 c
11-1066976000
jab~
2003-10-24 10:13
2004.05.02
KOLGraphic


6-1078229131
V@ler@n
2004-03-02 15:05
2004.05.02
Отлов IP-пакетов в сети


11-1065766982
Deimos
2003-10-10 10:23
2004.05.02
Где найти пример модуля для работы с JPEG


3-1081347600
начинаю-щий
2004-04-07 18:20
2004.05.02
Уникальное значение поля


11-1066369188
Ал
2003-10-17 09:39
2004.05.02
Как обработать нажатие F1 на любой форме?