Запросам вредит обновление статистики индексов

Запросы, планы, оптимизация запросов, ...

Модераторы: kdv, CyberMax

BPach
Сообщения: 21
Зарегистрирован: 21 фев 2007, 12:59

Сообщение BPach » 24 фев 2007, 20:16

Низкий поклона за разборку статистики.
kdv писал(а):В то, что этот индекс взялся как join для order by a57.val - я не верю.
Скорее план взят не оттуда. Т.к. при order by в плане будет или plan sort или слово order.
Великодушно прошу прощения, действительно, посмотрел внимательно и план от вышеприведенного запроса на самом деле такой как вы описываете:

Код: Выделить всё

PLAN JOIN (a57 ORDER VAL_STR_IDX1,a113 INDEX (VAL_STR_IDX5),a112 INDEX (VAL_STR_IDX5),a88 INDEX (VAL_BOOL_IDX5,VAL_BOOL_IDX1))
Дубликатные ключи, видимо, от того что в таблицах (в столбцах <tbl>_VAL) много одинаковых значений: в строковых - пустые строки, в числовых и датах - нули (база только начинается). Но, ведь это временно и, потом, почему в базе не может быть преобладающего количества одинаковых значений: мало ли что там может храниться. Впрочем, дубликаты, дубликатами, а план то меняется после обновления статистики, а дубликатные были и до и после.
Просто мучает вопрос: почему после массового insert'а статистика индексов была как бы "правильная" с точки зрения скорости выполнения запроса, а после обновления статистики - стала фиговой с этой же точки зрения. Следовательно существовало состоянии базы "какое мне надо". Если бы этого состояния не было, то и сравнивать было бы не с чем. И тогда оставалось бы ковыряться только в индексах. Что же это за лохматый зверь такой - статистика, которая жизнь портит.
Конечно, "руки" у разработчика должны расти из правильного места. Попробую воспользоваться вашими советами. Спасибо.

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 25 фев 2007, 00:24

Просто мучает вопрос: почему после массового insert'а статистика индексов была как бы "правильная" с точки зрения скорости выполнения запроса
статистика обновляется только тогда, когда ... см. хелп IBAnalyst :-)
т.е. статистика после заливки данных вообще не соответствовала. Поэтому план был "от балды". Когда статистика обновилась, оптмизатор стал строить более правильный план с его точки зрения. Но. Откуда ж ему знать особенность описанного мной распределения значений?
И статистика не стала "фиговой". селективность индекса стала именно такой, какова она и есть.

Насчет хреновости table order index на вот таких сильно дублирующихся ключах я писал на sql.ru:
http://www.sql.ru/forum/actualthread.as ... =2#2535391
здесь что group by что order by - результат один и тот же.
Поэтому такие индексы из order by лучше исключать вручную, до тех пор пока у статистики по индексам не будет гистограмм.
Что же это за лохматый зверь такой - статистика, которая жизнь портит.
еще раз рекомендую прочитать справку по IBAnalyst, про "плохие" индексы. Рекомендую смотреть хелп к русскому IBA, т.к. пока справка у русского и английского одинакова.

p.s. надеюсь, проблем с нахождением в ibanalyst.chm справки про "дополнительные вопросы и ответы" нет? А то был случай...

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 25 фев 2007, 00:26

много одинаковых значений: в строковых - пустые строки, в числовых и датах - нули (база только начинается)
если база "пустая", откуда там сотни тысяч значений???
Но, ведь это временно и, потом, почему в базе не может быть преобладающего количества одинаковых значений: мало ли что там может храниться
вот именно. если взять примитивную задачу - клиенты, товары, поставщики, то и тут может быть масса перекосов в разные стороны:

1. мало клиентов, много товаров и поставщиков
2. много клиентов, товаров и мало поставщиков
3. и т.д.
И во всех этих случаях при правильной статистике оптимизатор построит разные планы! Поэтому "прибивать план гвоздиком" нельзя, тем более если ваше решение предполагается устанавливать у разных потребителей вашего продукта.

И разумеется, имеющийся случай перекоса индекса тоже придется учитывать.

BPach
Сообщения: 21
Зарегистрирован: 21 фев 2007, 12:59

Сообщение BPach » 25 фев 2007, 01:34

kdv писал(а):если база "пустая", откуда там сотни тысяч значений???
SQL база имеет ОДИНАКОВУЮ структуру для любых задач (проектов, реализаций, как там еще можно назвать...). Таблицы базы в этом случае хранят значения полей так называемых справочников (для каждого типа данных предназначена своя таблица в базе). Если в структуре справочника десятки полей, то при заполнении незначительной их части (при большом количестве записей) и получаются сотни тысяч "пустых" значений, которые, как бы зарезервированы для последующего заполнения осмысленными значениями. Из-за такой организации и прибивать гвоздями план невозможно.
kdv писал(а):И разумеется, имеющийся случай перекоса индекса тоже придется учитывать.
Постепенно начинаю понимать и смысл статистики и игру с индексами. Много перелопатил материала на ibase.ru (IBAnalist тоже без внимания не остался). Благодарю за наводку на sql.ru, тоже достойный источник. Думаю, теперь выберусь из нехорошей ситуации. Кстати, из пары десятков проектов уже успешно работающих только этот преподнес подлянку. Потому и растерялся - настолько глубоко еще не копал.
Еще раз благодарю Дмитрия за участие и внимание (при такой-то занятости). Несколько утешает мысль, что этот материал может быть еще кому-то пригодится.

Ответить