Hello, Dmitry!
Dmitry Yemanov wrote:
2. да, была идея исключать такие индексы из "плохих", хотя бы
опционально, но начиная с FB 1.5 имя индекса FK/PK формируется по
имени constraint, поэтому критерий "имя индекса начинается с
RDB$FOREING" больше не работает.
RDB$RELATION_CONSTRAINTS.RDB$INDEX_NAME
опция "загружать метаданные" есть только в IBA 2.0.
Короче, ситуация такая:
1. индексы по FK строятся принудительно
2. плохая селективность может быть как у FK так и у любого другого индекса
3. индекс по FK, в отличие от обычного, служит для контроля
ссылочной целостности. Поэтому без удаления FK удален быть не может.
так что, через RDB$RELATION_CONSTRAINTS.RDB$INDEX_NAME
будет возможность показать, что конкретный "плохой" индекс
построен по ПК или ФК для FB 1.5/2.0.
Я уже раз десять тут повторял, что понятие "плохой" связано
только с общей селективностью. Если большинство запросов
выбирают по такому индексу малое количество ключей, то индекс
будет работать БЫСТРО. IBAnalyst не знает и знать не может,
какие запросы выполняются в приложениях, и как они используют
эти индексы.
p.s. спасибо Ded-у за комментарий.
--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
