Эффективность индекса

← →
atruhin © (2005-10-10 14:09) [0]

Firebird 1.5. есть таблица в которую пишется лог. событий. Одно из полей timestamp в этом поле данные получаются последовательные. Основные выборки идут по диапазонам данного поля. Приблизительный рабочий объем данных 1-3 млн. записей.
В литературе встречал, что при последовательных данных индексы теряют эффективность, из за перекоса дерева. Обоснованны ли опасения о потере производительности? Если да , то что делать?

← →
Sergey13 © (2005-10-10 14:12) [1]

2 atruhin © (10.10.05 14:09)
Делов-то. Грохни индекс и проверь запросы. Восстанови индекс если появится замедление.

← →
Fay © (2005-10-10 14:14) [2]

2 atruhin © (10.10.05 14:09)
"Потеря производительности" в сравнени с full scan?
Не переживайте, индекс не повредит 8)

← →
sniknik © (2005-10-10 14:25) [3]

> ... в этом поле данные получаются последовательные.
сделай индекс по нему кластерным (если оно в FB означает тоже что в MSSQL ;)

← →
Fay © (2005-10-10 14:28) [4]

2 sniknik © (10.10.05 14:25) [3]
1) В FB нет кластерных индексов
2) Это не прибавит скорости

← →
Desdechado © (2005-10-10 14:45) [5]

1. можно пересобирать статистику индексов (немного помогает)
2. перекос возникает при последовательном ДОБАВЛЕНИИ. Иногда можно делать backup-restore для уничтожения перекоса

← →
Fay © (2005-10-10 15:57) [6]

2 Desdechado © (10.10.05 14:45) [5]
>> backup-restore для уничтожения перекоса
Сурово 8)
alter index INDEX_NAME inactive;
alter index INDEX_NAME active;

← →
atruhin © (2005-10-10 16:03) [7]

>>"Потеря производительности" в сравнени с full scan?
Я об этом не говорил. :)
>>2. перекос возникает при последовательном ДОБАВЛЕНИИ
А вот эта ситуация у меня и есть. Т.к. данное поле время добавления записи.
>>alter index INDEX_NAME inactive;
>>alter index INDEX_NAME active;
Хм, а вот это нужно попробовать.

← →
Sergey13 © (2005-10-10 16:12) [8]

2[7] atruhin © (10.10.05 16:03)
>Хм, а вот это нужно попробовать.
Только в клиентскую прогу это вставлять не надо. 8-)

← →
Fay © (2005-10-10 16:29) [9]

2 Sergey13 © (10.10.05 16:12) [8]
А в какую ещё прогу это можно вставить?

по расписанию запускать какой-нить батник, который и будет это делать
а в клиент действительно лучше не совать (если он не деинственный, конечно), а то другим юзерам хана будет

я ни понял
"пересобирать статистику индексов"
и
"backup-restore для уничтожения перекоса/alter index INDEX_NAME"

вроде как это одно и тоже в приницпе.
И суть этого, чтоб статистика индекса свежая была, и он заюзался когда надои не юзался когда ненадо.
но все это неважно, в приницпе, пока план запроса показывает то что и ожидается.
p.s. отключить лишний индекс проще всего в запросе например "id+0="

>>"пересобирать статистику индексов"
>>"backup-restore для уничтожения перекоса
статистика и перекос дерева - две большие разницы.
Вообще вопрос, пока чисто теоритический. Т.к. в реальном приложении возможно хватит производительности в любом варианте.

естественно, разные
статистика позволяет намекнуть оптимизатору на целесообразность использования индекса
перекос приводит к долгому поиску по дереву индекса (глубина дерева больше 3 - это почти завал)
при перекосе тормоза могут быть вполне реальные, по практике говорю, даже при глубине 4 уже заметно
глубину можно проверить одной из утилит FB

Эффективность индекса Найти похожие ветки