Можно ли ускорить Delete

← →
Петрович © (2003-01-30 10:20) [0]

Так получается, что Delete в базе выполняется слишком долго. Если к Select"у можно применить Plan, который ускоряет работу, то к Delete нельзя. Причем деактивировать индексы к сожалению не получается в пределах одной транзакции ... или я не прав? То что тормозит Delete подгребаемые оптимизатором индексы однозначно ясно ... при этом он зараза цепляет почти все из-за чего естественно и жутчайшие тормоза.

Может кто-нибудь что-нибудь посоветует?

← →
Reindeer Moss Eater (2003-01-30 10:23) [1]

Убить индек, удалить нужные (в смысле ненужные более) записи, восстановить индексы

← →
passm © (2003-01-30 10:33) [2]

Петрович © (30.01.03 10:20)> В данном деле индексы тоже часто полезны. Смотри условие WHERE а так же ссылки на данныю таблицу (добавление индекса на внешний ключ, возможно, поможет) и триггеры.

← →
Петрович © (2003-01-30 10:35) [3]

Убью я индекс, а он же гад убъется не в контексте текущей транзакции. А кто-то в этот момент попробует использовать чего-нибудь, где у меня используется Select с Plan"ом, содержащим удаленный индекс ... и ничего у него не получиться!

← →
Петрович © (2003-01-30 10:38) [4]

passm не совсем понял, что ты хотел сказать. :(

Проблема в основном та, что индексы, которые подгребает Delete являются ссылочными. т.е. которые по Reference создались.

← →
passm © (2003-01-30 10:48) [5]

Петрович © (30.01.03 10:38)> Вижу, что понял :)
FireBird создает индексы при создании внешнего ключа?
Если да, то, IMHO, напрасно - не всегда полезно.

← →
Петрович © (2003-01-30 10:54) [6]

passm © (30.01.03 10:48)>

Угу ... особенно если этот паразит, потом, вместо одного индекса гребет все доступные. ;o(

Прямо и не знаю что делать ... представляете, сформирует сводный заказ пользователь из 15тыс пришедших за 13минут (процедура формирования такая), смотрит пришло еще два заказа в довесок 15тысячам. Ладно думает, сейчас переформирую ... ан нет! Удаление сформированного заказа длится ... фиг его знает сколько, я не дождался! ;o( Вот и думаю ... как бы извратиться ... и ничего в голову не лезет.

← →
passm © (2003-01-30 11:14) [7]

Петрович © (30.01.03 10:54)> Наращивать мускулы (железо; рэйд и пр.) :)

← →
Петрович © (2003-01-30 11:43) [8]

passm © (30.01.03 11:14)>

Скорее меня прибьют чем мускулы нарастят!

← →
Alexandr © (2003-01-30 11:51) [9]

а ты не удаляй, а помечай на удаление.
А удаляй потом, позже раз в неделю по-выходным...
Или вообще никогда.

← →
Петрович © (2003-01-31 08:42) [10]

Alexandr © (30.01.03 11:51)>

Пришел к такому же выводу! Спасибо что поддержали! :)

← →
Виталий Панасенко (2003-01-31 08:56) [11]

Или использовать Yaffil. Там, кажись план можно указывать и для update/delete. Но весь прикол в том, что его (Дятла) ну никак немогу установить... Пробовал и снепшот, и инсталлятор. Снепшот по-своему дурью мается, а инсталлятор кричит, что у меня версия WinInst древняя, хотя затянул с указанной ссылки... А по параметрам Дятел вроди бы намного быстрее и "умнее" как ИБ так ФБ. Но ...

← →
Дмитрий Ф. (2003-01-31 09:00) [12]

FireBird 1.5 это же еще не отлаженный сервак, к тому же помниться разработчики грозились сделать форенкеи без индексов, хочеш что-то путное - лучше используй FireBird 1.02

Это ж эксперементировать с переходом на "дятла" нужно. А работа-то не ждет! ;O(

И вообще, я думал, что на 1.5 сидел, но мне тут один из разработчиков FireBird мозни впраил. Хотя все равно не ускорилось нифига. Может Дмитрий и прав насчет снятия индексов с форинкей, ибо чуть-чуть даже замедлилось. Но замедлилось не настолько уж сильно.

2Петрович © (04.02.03 09:20)
Насчет FB не скажу, но может быть индексы на ФК работают там как в оракле. У оракула помнится при апдейте главной таблицы при наличии индекса на ФК блокируются только нужные записи в подчиненной таблице, а при отсутствии такового блокируется вся таблица. Может и в FB такая же схема. Так что отрубать индексы я бы поостерегся. Тем паче что не помогло это тебе.
А как ты удаляешь? По каскаду или явно ручками по всем таблицам? Может с этим поиграться?

Еще один совет
Попробуй добавить PK из одного поля
Проверь производительность удаления с помощью TIBTable
этот компонент для удаления использует RDB$DB_KEY, который в свою очередь является уникальным индексом в пределах БД

Можно ли ускорить Delete Найти похожие ветки