Тормозит запрос на FB 2.0

Запросы, планы, оптимизация запросов, ...

Модераторы: kdv, CyberMax

Ответить
ess
Сообщения: 21
Зарегистрирован: 26 июл 2006, 10:51

Тормозит запрос на FB 2.0

Сообщение ess » 28 июл 2006, 11:03

Прошу помочь с запросом!

Вроде тривиальная задача

Есть таблица:
--------------------------------
ID integer *PK
ID_COUNTER integer *FK
DATE_VALUE date
VALUE double precision
...
--------------------------------
CREATE INDEX POTREB_IDX_DATE_VALUE ON POTREB (DATE_VALUE)
--------------------------------

Необходимо выбрать последнюю запись на заданную дату (:begin_period).

Есть два варианта запроса:

1.

Код: Выделить всё

SELECT FIRST 1 
    ID,
    DATE_VALUE,
    VALUE
FROM
    POTREB
WHERE
    (ID_COUNTER = :VAR_ID_COUNTER)
     AND (DATE_TEK <= :begin_period)
ORDER BY
    DATE_TEK DESC
2.

Код: Выделить всё

SELECT
    ID,
    DATE_VALUE,
    VALUE
FROM
    POTREB
WHERE 
    (ID_COUNTER = :ID_COUNTER)
    AND (DATE_TEK =
        (SELECT
            MAX(S.DATE_VALUE)
         FROM
             POTREB S
         WHERE
             (S.ID_COUNTER = :ID_COUNTER)
             AND (S.DATE_VALUE <= :begin_period)
        )
    )
В таблице POTREB 2,5млн. записей, по ID_COUNTER выбирается меньше сотни.

Оба запроса прекрасно работали на FB 1.5.3, но на FB 2 нещадно тормозят!!!
(130 мс на FB 1.5.3 против 620 на FB 2.0).

Игрался с индексом по DATE_VAL, но ничего не помогло.

Спасибо...

CyberMax
Заслуженный разработчик
Сообщения: 638
Зарегистрирован: 31 янв 2006, 09:05

Сообщение CyberMax » 28 июл 2006, 11:29

Прочитай вот это: http://forum.ibase.ru/phpBB2/viewtopic.php?t=2389. Ждем доп. инфы.

ess
Сообщения: 21
Зарегистрирован: 26 июл 2006, 10:51

Сообщение ess » 28 июл 2006, 11:40

Планы запросов по-порядку:

1.
PLAN SORT ((POTREB INDEX (FK_POTREB_ID_COUNTER, POTREB_IDX_DATE_VAL)))


2.
PLAN (S INDEX (FK_POTREB_ID_COUNTER, POTREB_IDX_DATE_VAL))(POTREB INDEX (FK_POTREB_ID_COUNTER, POTREB_IDX_DATE_VAL))

селективность индекса POTREB_IDX_DATE_VAL = 0,000023458...
Версия сервера WI-V6.3.0.12710 Firebird 2.0 RC3

dimitr
Разработчик Firebird
Сообщения: 888
Зарегистрирован: 26 окт 2004, 16:20

Сообщение dimitr » 28 июл 2006, 11:42

1. DATE_TEK и DATE_VALUE часом не одно и то же? :-)
2. Какие были планы на 1.5?

dimitr
Разработчик Firebird
Сообщения: 888
Зарегистрирован: 26 окт 2004, 16:20

Сообщение dimitr » 28 июл 2006, 11:45

3. Селективность индекса FK_POTREB_ID_COUNTER?

dimitr
Разработчик Firebird
Сообщения: 888
Зарегистрирован: 26 окт 2004, 16:20

Сообщение dimitr » 28 июл 2006, 11:47

а вообще, если скорость этого запроса важна, я бы построил desc-индекс по дате

ess
Сообщения: 21
Зарегистрирован: 26 июл 2006, 10:51

Сообщение ess » 28 июл 2006, 11:52

Date_tek это DATE_VAL (Апечатка :oops: ),
а планов под 1.5 под рукой нет.

Если не оглядываться на 1.5, какое можно найти решение еще?

ess
Сообщения: 21
Зарегистрирован: 26 июл 2006, 10:51

Сообщение ess » 28 июл 2006, 11:56

селективность FK_POTREB_ID_COUNTER 0.00000750

Странно но index DESC по date_val ничего не дал.

dimitr
Разработчик Firebird
Сообщения: 888
Зарегистрирован: 26 окт 2004, 16:20

Сообщение dimitr » 28 июл 2006, 11:58

ess писал(а):Странно но index DESC по date_val ничего не дал.
у первого запроса должен был измениться план. Это произошло?

dimitr
Разработчик Firebird
Сообщения: 888
Зарегистрирован: 26 окт 2004, 16:20

Сообщение dimitr » 28 июл 2006, 12:01

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

CyberMax
Заслуженный разработчик
Сообщения: 638
Зарегистрирован: 31 янв 2006, 09:05

Сообщение CyberMax » 28 июл 2006, 12:06

В список доп. информации добавил "Статистика выполнения запроса" :). Что-то я ее из виду выпустил.

ess
Сообщения: 21
Зарегистрирован: 26 июл 2006, 10:51

Сообщение ess » 28 июл 2006, 13:00

Cтатистика по первому запросу
для FB 1.5

------ Performance info ------
Prepare time = 0ms
Execute time = 109ms
Avg fetch time = 109,00 ms
Current memory = 1 601 588
Max memory = 1 730 348
Memory buffers = 2 048
Reads from disk to cache = 14
Writes from cache to disk = 3
Fetches from cache = 157


для 2.0

------ Performance info ------
Prepare time = 0ms
Execute time = 516ms
Avg fetch time = 516,00 ms
Current memory = 5 563 988
Max memory = 5 813 868
Memory buffers = 2 048
Reads from disk to cache = 17
Writes from cache to disk = 3
Fetches from cache = 551

прошу учесть, что 2.0 удал.сервер, а 1.5 локальная машина

dimitr
Разработчик Firebird
Сообщения: 888
Зарегистрирован: 26 окт 2004, 16:20

Сообщение dimitr » 28 июл 2006, 13:21

ну и раз уж ты до 1.5 таки добрался, то может план покажешь? :-)

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Сообщение WildSery » 28 июл 2006, 13:24

В первом плане ИМХО индекс по дате лишний, всё равно сортировка идёт, эти 100 записей может быть быстрее перебрать так, чем ещё индекс приклеивать.
Попробуй.

И ещё - можно попробовать вот такой индекс:
CREATE DESCENDING INDEX POTREB_IDX_1 ON POTREB (DATE_VALUE,ID_COUNTER)
чтобы только он использовался. Тоже может быть быстрее.

ess
Сообщения: 21
Зарегистрирован: 26 июл 2006, 10:51

Сообщение ess » 28 июл 2006, 13:38

Планы FB 1.5

1.
PLAN SORT ((POTREB INDEX (FK_POTREB_ID_COUNTER)))

2.
PLAN (S INDEX (FK_POTREB_ID_COUNTER))(POTREB INDEX (FK_POTREB_ID_COUNTER))

ess
Сообщения: 21
Зарегистрирован: 26 июл 2006, 10:51

Сообщение ess » 28 июл 2006, 13:39

Вот те раз, а 1.5 вообще индекс по DATE_VAL не испоьзует :shock:

dimitr
Разработчик Firebird
Сообщения: 888
Зарегистрирован: 26 окт 2004, 16:20

Сообщение dimitr » 28 июл 2006, 13:42

так я и думал. В 2.0 придется хинтом подрулить.

ess
Сообщения: 21
Зарегистрирован: 26 июл 2006, 10:51

Сообщение ess » 28 июл 2006, 13:43

:P :P :P Всем спасибо, что наставили на путь истинный, проблема ясна. 16:42 рабочий день закончен!!! :lol:

Ответить