Попадание даты в диапазон

wolph

Как быстрее всего проверить попадание даты (datetime) в диапазон (BETWEEN, сравнение, DATEDIFF или еще чего)? Стоит ли для поля даты создавать индекс?
21 ответ

wolph

Думаю, что BETWEEN на индексированное поле даты должен с хорошей производительностью отработать.


wolph

Сервер PIII 500 x 2, таблица ~150.000 записей. Селект (условие-subj) выполняется 40 сек. Это нормально?


wolph

А что говорит план выполнения?


wolph

Сервер PIII 500 x 2, таблица ~150.000 записей. Селект (условие-subj) выполняется 40 сек. Это нормально?
А сколько записей селект возвращает?Индекс на поле даты стоит?


wolph

Индекс стоит. Селект возвращает суммуы по 2-м полям.


wolph

Селект возвращает суммуы по 2-м полям.
Т.е. в резалтсете все 150 000 записей?


wolph

2wolph:Вы бы что ли уже текст запроса привели до кучи...И то, что Pkarklin советует делать ВСЕГДА делайте...:))) (Это я про план запроса)


wolph

Если в запросе есть преобразования типов, то это резко замедлит запрос,причём независимо от того, есть индекс или нет.40 сек. ИМХО это много. Норма менее 10 сек... :)


wolph

Индекс должен быть кластерный по этому полю.


wolph

DATEDIFF приведет к полному сканированию таблицы. Насчет BETWEEN: он является эквивалентом >= AND =<, причем ПОЛНЫМ. Есть мнение, что SQL преобразует предварительно BETWEEN в>= AND =<.


wolph

Создаю кластерный индекс. А он ****************' table- Unable to create index 'IX_WebProxyLog'. ODBC error: [Microsoft][ODBC SQL Server Driver][SQL Server]Could not allocate space for object '(SYSTEM table id: -674401337)' in database 'LogDB' because the 'PRIMARY' filegroup is full.[Microsoft][ODBC SQL Server Driver][SQL Server]The statement has been terminated.Места на диске, что-ли, не хватает?


wolph

Добавь в параметрах базы предел роста файлов базы.


wolph

Возможно ЛОГ переполнен. Используй shink или
Declare @db sysname
set @db = db_name()
BACKUP LOG @db WITH TRUNCATE_ONLY


wolph

Сейчас там "Unrestricted file growth"Кстати, запрос простейший:SELECT @Sent = sum(bytesrecvd), @Recived = sum(bytessent)FROM **************** (logDate BETWEEN @StartDate and @EndDate)


wolph

Лог от ISA обрабатываешь?Так он растет как на дрожжах :(Я бы написал пару триггеров, которые всю статистику складыва ли бы в отдельные таблы (в момент появления) записей, и уже их и юзал бы для отображения статистикиА то вдруг тебе еще захочется иметь статистику по url, причем не по конкретным кликам, а по сайтам (например: сколько данный чел. скачал с сайта sql.ru) - так у тебя тогда во where лайки появятся с % в начале, а им уже до фени будут индексы :(ИМХО - эффективнее будет.Ну или OLAP прикрути :)


wolph

А как ты догадался :)Самое смешное, статистику по url я уже сделал, и считается она ненамного медленнее. А насчет триггеров - мысль интересная, стоит подумать.


wolph

2paparome Я вот тут подумал насчет триггеров. Идея привлекательная, но возникает вопрос: а не опухнет ли сервер от такого количества вызовов?


wolph

2paparome Я вот тут подумал насчет триггеров. Идея привлекательная, но возникает вопрос: а не опухнет ли сервер от такого количества вызовов?
Не знаю - не пробовал :)Но если, не опухнет, то статистика у вас будет уже в готовом виде храниться+ лог можно будет чистить не боясь потерять стистику


wolph

Возможно, что как раз тот случай для создания покрывающго индекса.Но точно сказать сложно - хорошо бы видеть весь запрос.


wolph

SELECT
@Sent = sum(bytesrecvd),
@Recived = sum(bytessent)
FROM ***********
WHERE (logDate BETWEEN @StartDate and @EndDate)
знакомая вещь :)у меня были грабли что sum(bytesrecvd) легко переполняет размер Int


wolph

Можно по всем трем полям сделать покрывающий индекс... Или, как уже предлагали, по дате - кластерный. Но принципиально быстрее не будет. Хотя может стать ощутимо быстрее. Я за ведение триггером таблицы сгруппированных значений сразу в разрезе дат. Или за OLAP. Это будет качественное / революционное изменение.