Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

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

Desdechado (2005-10-10 18:18:00) [1]
естественно, разные
статистика позволяет намекнуть оптимизатору на целесообразность использования индекса
перекос приводит к долгому поиску по дереву индекса (глубина дерева больше 3 - это почти завал)
при перекосе тормоза могут быть вполне реальные, по практике говорю, даже при глубине 4 уже заметно
глубину можно проверить одной из утилит FB

atruhin (2005-10-10 17:06:00) [2]
>>"пересобирать статистику индексов"
>>"backup-restore для уничтожения перекоса
статистика и перекос дерева - две большие разницы.
Вообще вопрос, пока чисто теоритический. Т.к. в реальном приложении возможно хватит производительности в любом варианте.

Alexandr (2005-10-10 16:51:00) [3]
я ни понял
"пересобирать статистику индексов"
и
"backup-restore для уничтожения перекоса/alter index INDEX_NAME"

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

Desdechado (2005-10-10 16:33:00) [4]
по расписанию запускать какой-нить батник, который и будет это делать
а в клиент действительно лучше не совать (если он не деинственный, конечно), а то другим юзерам хана будет

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

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

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

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

Desdechado (2005-10-10 14:45:00) [9]
1. можно пересобирать статистику индексов (немного помогает)
2. перекос возникает при последовательном ДОБАВЛЕНИИ. Иногда можно делать backup-restore для уничтожения перекоса

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

sniknik (2005-10-10 14:25:00) [11]
> ... в этом поле данные получаются последовательные.
сделай индекс по нему кластерным (если оно в FB означает тоже что в MSSQL ;)

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

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

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »