Hello, Dmitry!
You wrote on Wed, 21 Jun 2006 10:22:43 +0400:
DY> Такой план будет очень хорош при <3 и очень плох при >3. Оптимизатор
DY> учитывает средний вариант, требующий скана половины таблицы.
Дим, я тоже хотел бы спросить про оптимизатор в FB 2.0... Попытались
перевести базу на него и неудачно. Причина в возникших ниоткуда тормозах.
После недолгого разбирательства откатились обратно на 1.5.3. Вопрос же вот в
чем - есть таблица DOCS (чуть больше 1 млн записей). Есть запрос:
select count(*)
from DOCS
where DOC_DATE between ?DF and ?DT
and FROM_ID = ?FROM_ID
and DOCUMENT_ID = 2
FROM_ID и DOCUMENT_ID - внешние ключи, по полю DOC_DATE есть индекс.
Селективности по индексам:
по DOC_DATE - 0,00048169
по FROM_ID - 0,00017614
по DOCUMENT_ID - 0,03333333
план для запроса на FB 1.5.3 и на FB 2.0.12691 (на этой же базе, т.е. на ODS
10.1):
PLAN (D INDEX (FK_DOCS_FROM, DOCS_IDX_DATE))
Отрабатывает очень быстро с минимумом чтений (ну, например, за период -
254). Переводим базу в ODS 11.0 и получаем план
PLAN (D INDEX (FK_DOCS_FROM, FK_DOCUMENT_ID))
Количество индексных чтений из таблицы порядка 20 тыс с соответствующими
тормозами... Заставить оптимизатор использовать индекс по DOC_DATE удалось
только при записи запроса в таком виде:
select count(*)
from DOCS
where DOC_DATE between ?DF and ?DT
and FROM_ID+0 = ?FROM_ID
and DOCUMENT_ID+0 = 2
в любом другом варианте индекс по DOC_DATE не используется вообще. Это что -
приоритет по индексам во внешних ключах, даже если там селективность много
ниже?
PS: Подсунуть такой план на ODS 10.1 в явном виде не получилось. Сервер его
не принял.
--
With best regards, Yuri Grabar.
--~--~---------~--~----~------------~-------~--~----~
-~----------~----~----~----~------~----~------~--~---
