from:"Александр Свириденков"

Множественные апдейты одной записи

2011-02-07 Пенетрантность Александр Свириденков

Где-то мне попадалось что сильно ускоряли множественные апдейты одной
записи в 2.5, или ошибаюсь?
Есть древовидная таблица с триггером after delete типа update parent
set childs=childs-1
В ней 3000 записей.
Если удалять с отключенным триггером, меньше секунды, с включенным 20
минут.
Как-то многовато?

FB 2.5 последний

Re: Странный план в 2.5.0.26074

2011-01-15 Пенетрантность Александр Свириденков

Т.е. речь про:

select * from cont_res cr join contracts ct on cr.cont_id=ct.cont_id
where cr.serv_id=14 and cr.resource is null
?

Да

Твоя правда :-) Кстати, NOT NULL ты таки снять можешь (если там UK, а не
PK). Но не удалить PK, это да.

А на что тогда версионность метаданных? Сервер имеет полное право
работать в препарированном запросе
по старой версии

Насколько я понимаю, тут засада в композитном индексе, где NULL - не
последний сегмент. Я недавно это объяснял Болтику, цитирую:

Это особенность реализации нуллов в индексах. Для ASC-индексов нуллы
хранятся как ключи нулевой длины. Поэтому при поиске на частичное
соответствие (полей в индексе больше чем в запросе) нулл будет равен
любому другому ключу. Аналогия для индекса с 4 сегментами:

A = a and B = b and C = c : field like 'abc%'
A = a and B = b and C is null : field like 'ab%'

.е. нулл после сегмента B есть, но его при поиске не видно, т.к. это
ключ нулевой длины. Отсюда и шире выборка, больше чтений.

Таким образом, де-факто имеем поиск лишь по первому сегменту
композитного индекса, а им выбираются все 100% значений.

Ну значит неправильное какое-то хранение индекса выбрано, если он
приводит к неожиданным
тормозам там, где их совсем не ожидаешь, и даже по плану не отследишь
Сечас время такое, что на объемах экономить не надо. Диски гигантские,
память дешевая.
А вот скорость оптимизировать наоборот - надо.

Попробуй пересоздать композитный PK как DESC-индекс. В этом случае нуллы
хранятся в виде 0xFF и все должно работать как ожидается.

В общем, я вышел из положения создав дополнительный индекс на CONT_RES
по двум полям.
Благо, сервер его успешно подхватил

Ну, или если ты заранее знаешь, что эта выборка по PK фиктивная, то
добавь в предикат для CONT_RES любое значения столбца CONT_ID, тогда
индексный ключ станет полным и нуллы начнут искаться (и не находиться).

Да эта выборка используется как подзапрос другого запроса, и
получается что в нее в 95%
случаев должен попадать NULL, вот и заметил тормоза

Спасибо за участие и консультацию :)
P.S.
Так ждем 3.0 с реальной многопроцессорностью, что аж сил нет :)

62 matches

Mail list logo