Статистика индекса ASE 15.x в второстепенных атрибутах - PullRequest
Новая
       27

Статистика индекса ASE 15.x в второстепенных атрибутах

3 голосов
/ 09 ноября 2011

Если мы создадим такой индекс: 

create nonclustered index idx_person on person(gender, name)

в ASE 12.5 будет создана статистика (точнее гистограмма) для основного атрибута (пола), но ничего не будет сделано для имени младшего атрибута.

Из-за этого оптимизатор может выбрать наихудший план запроса при выборе типа: 

select * from person
where gender = 'M'
and name = 'John Doe'

Возможно, он выберет наихудший план запроса, поскольку он даст значения селективности по умолчанию для имени столбца. При этом сканирование таблицы может быть лучше, чем выбор индекса.

!

Что я хочу знать, так это если в ASE 15.x при создании индекса с несколькими столбцами статистика запускается для всех столбцов индекса?

Или, если нам нужно использовать следующие команды для обновления статистики индекса: 

update statistics person(name)

update index statistics person index_person

Заранее спасибо! :)

1 Ответ

3 голосов
/ 16 ноября 2011

По умолчанию вы не получаете статистику по второму и последующим столбцам, я полагаю, потому что Sybase должен сделать больше обработки и использовать tempdb для их компиляции. Поэтому вы должны решить, какие из ваших индексов должны иметь все свои столбцы со статистикой.

Если у вас версия v15 и у вас установлен уровень оптимизации "mix" или "dss", у вас, вероятно, возникнет проблема, когда вы не сохраняете статистику по всем столбцам индекса, поскольку оптимизатор не может легко получить слияние и хэш-соединения правильно без всей статистики столбца индекса. На v12.5 то же самое применимо, если у вас включен MERGE JOIN.

Я думаю, что, скорее всего, у вас будет больше таких проблем, чем неправильных планов, просто из-за отсутствия гистограммы во 2-м и последующих столбцах, хотя я думаю, что это зависит.

Вы можете использовать функцию DATACHANGE, чтобы узнать, какие таблицы изменились более чем на какой-то процент, который вы даете, чтобы вы могли писать сценарий оболочки (или любой другой), который периодически (раз в час / несколько часов / день / начало пакет / конец пакета / и т. д.) проверяет базу данных и обновляет статистику для затронутых таблиц. (На самом деле я не совсем уверен, что это на 12.5 - вполне может быть только v15.)

...