Привет всем!

Желая ускорить работу запросов, я перестроил все индексы в БД. Проверил на нескольких запросах, вроде они стали быстрее раза в 4. Но вот есть такая процедура:


CREATE PROCEDURE DoCalc
@DateCalculated VARCHAR(100) = NULL
AS

UPDATE view1
SET a1 = a2 ,b1 = b2
WHERE @DateCalculated IS NULL
OR DateCalculated IS NULL
OR DateCalculated = CONVERT(DATETIME,DateCalculated,120)
GO

Процедура работает минут 5, после чего я ее останавливаю, так и не дождавшись результата. До перестроения индексов она отрабатывала минуты за 2. Теперь вставляю такой комментарий:



CREATE PROCEDURE DoCalc
@DateCalculated VARCHAR(100) = NULL
AS

UPDATE view1
SET a1 = a2 ,b1 = b2
WHERE /*@DateCalculated IS NULL
OR */DateCalculated IS NULL
OR DateCalculated = CONVERT(DATETIME,DateCalculated,120)
GO


Процедура отрабатывает секунд за 10. Маразм крепчал.
view1 довольно сложный и в плане UPDATE я не могу толком разобраться.

Кто-нибудь может хотя-бы приблизительно сказать куда копать? Может, какие-нибудь подсказки оптимизатору помогут?

Заранее спасибо.

2Nickolay
> как это понять?
Что именно? "@DateCalculated VARCHAR(100) = NULL"? Как параметр, у которого значение по умолчанию NULL, а не по умолчанию -- какое угодно.

> если не считать последнего условия, которое по моим
> понятиям всегда истинно, код получается примерно таким:
М-дя...


2KirillovA:
> Проверь наличие автостатистик или перестрой их.
Сделал. Не помогает.

> Натрави ее на базу и погляди - у всех ли таблиц везде
> стоит флаг - ON.

Как назло -- у всех стоит. :-(

Блин! Перенес @DateCalculated IS NULL из начала WHERE в конец; и -- готово -- 12 секунд.

> нужно так.....
> WHERE DateCalculated IS NULL
> OR DateCalculated = CONVERT(DATETIME,DateCalculated,120)

Не, @DateCalculated IS NULL -- нужно. Это означает, что
если перцедура вызвана без параметра, то -- надо изменить
все представление.

Мне кажется, что когда @DateCalculated IS NULL стоит первым во WHERE -- дубовый оптимизатор проверяет на это условие каждую строку представления (а их там -- 7 млн.). А когда последним -- только строки, прошедшие через фильтр других условий (несколько тысяч).

> Чего-то я не понимаю? Если @DateCalculated IS NULL то и
> все условие в WHERE будет истино. Тогда обновляется вся
> таблица, а если оно ложно то update можно упростить и
> оставить только DateCalculated IS NULL OR DateCalculated =
> CONVERT(DATETIME,DateCalculated,120)
> Что я понял не правильно?

Ну да, так все и есть. Я пробовал сделать

IF @DateCalculated IS NULL BEGIN
UPDATE view1
SET a1 = a2, b1 = b2
END
ELSE BEGIN
UPDATE view1
SET a1 = a2, b1 = b2
WHERE DateCalculated IS NULL
OR DateCalculated = CONVERT(datetime,@DateCalculated, 120)
END

но это на скорость не вляет.

Кстати, на счет применения @DateCalculated IS NULL после того, как строки прошли отсев по другим условиям, я не прав. Это было бы верно в случае объединения условий опреатором AND, а тут -- OR.

Вобщем, логика оптимизатора мне совсем не понятна. К тому же, при каждом серьезном изменении структуры БД или самих данных он может так поменять план запроса, что прийдется заново настраивать производительность запросов. А если применять подсказки, то -- сегодня они могут помочь, а через полгода -- начнут мешать. Может лучше вместо 1 сложного запроса или представления писать процедуру с кучей простых запросов, с временными таблицами и максимальным
использованием процедурных возможностей T-SQL.

Это уже так -- в порядке общей жалобы на жизнь.