Здравствуйте.

Хотелось бы поинтересоваться таким вопросом в приложении к DB2.

Из чего следует исходить, определяя порядок следования полей при создании индекса?

Вот, в частности, нашел такую статью: http://www.sql.ru/faq/faq_topic.aspx?fid=285

ASCRUS Чем нужно руководствоваться при создании составных индексов:
1. Первыми ставить поля, обладающие лучшей выборочностью индекса.
2. Первыми ставить поля, для которых будет меньшая разветвленность.
3. Стремиться к минимальному числу уровней индекса, стараться избегать использования в составных индексах большого кол-ва полей и длинных полей. Главная задача индекса - это ограничить круг выбираемых записей до приемлемого по скорости уровня выборки, а не обхвата значений всех полей, использующихся в выборке.
4. Помнить о правилах булевых операций для оптимизатора и первыми в индексе ставить поля, на которых в операциях выборок идет сравнение на равенство (=) и вхождение в список значений (IN). Поля, фильтрующиеся по интервалам периодов значений (>, <, >=, <=, BETWEEN) нужно ставить в конец списка полей индекса. Если на несколько полей используются такие операции, то в индексе необходимо указать только одно из них, так как оптимизатор ASA не будет использовать далее идущие в индексе поля. Для выбора наиболее оптимального такого поля следует так же руководствоваться пунктами 1, 2 и 3.

Насколько эти рекомендации общи? Насколько это применительно к DB2? В обсуждении статьи, в частности, были оспорены п.1 и п.2 в применении к Oracle...

Конечно, я понимаю что многое ещё зависит от конкретных условий, как то: структурf таблицы, объемы данных и запросы которые на этой таблице исполняются.

Опишу ситуацию... Таблица примерно с 20-ю полями, в основном INTEGER-ы, несколько VARCHAR(..) и TIMESTAMP. Причем год, месяц, день и час дублируются в отдельных полях

ryear INTEGER,
rmonth INTEGER,
rday INTEGER,
rhour INTEGER

также есть поля

event_type VARCHAR (1) - может принимать только 2 значения, по этому полю все записи разделяются на две группы в соотношении примерно 1/4 или 1/5.
protocol_command_id INTEGER - принимает значения от 1 до 10

Первая группа запросов на таблице, в общем виде, это выбор по заданным ryear, rmonth, rday, rhour, event_type, protocol_command_id. Остальные поля либо суммируются, либо игнорируются, либо по ним происходит группирование.

Вторая группа запросов это запросы по интервалу заданному на поле

tm TIMESTAMP

и строго заднных

event_type VARCHAR (1),
operator_id INTEGER ,
provider_id INTEGER,
service_id INTEGER

Объемы... Ограничения сверху нет, но миллионы и сотни миллионов записей вполне возможны. В первую очередь необходимо чтобы созданные индексы сильно не тормозили добавление в таблицу (нужно обеспечить скорость порядка нескольких тысяч запросов в секунду, по крайей мере не ухудшить уже достигнутые 8000). Во вторую очередь нужно чтобы вышеописанные запросы выполнялись... Ну, не более чем несколько минут, несколько десятков минут. И при этом не тормозили добавление.

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

Да, и ещё, поля ryear, rmonth, rday, rhour введены с целью оптимизации производительности запросов, но их целесообразность спорна... Может быть от них можно совсем отказаться?

Внешних ключей нет, джоинов тоже.

Просто выбор из таблицы 4-х целочисленных полей плюс count(*) по условию на других полях (rday, rmonth, етк, описано в предыдущем посте), простое группирование по тем самым выбраннам INT-ам.

В другом запросе по сути тоже самое, только вместо count(*) sum(..) по одному из полей.

Таблица проектировалась в первую очередь из того, какие данные она должна хранить.

Гонял уже db2advis на эту тему.
Есть подозрение, что у него есть такая особенность... он вообоще говоря работает не со структурой таблицы+запросы, а с конкретными данными таблицы. Т.е. если у меня в таблице на момент тестирования будут некоторые данные, он мне даст советы по оптимизации запросов именно на этих данных. А когда приложение будет уже реально тестироваться, данные будут, скажем так, более разнородные, индекс созданный по совету db2advis не будет оптимальным. Или я ошибаюсь?

Описка, "приложение будет уже реально тестироваться"="приложение будет уже реально работать"

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

Victor Metelitsa , тестирование производится на "сгенеренных" данных объемом... Ну сейчас вот около 30 млн. записей. По поводу их достоверности...
Проблема вся в том, что сколько там в итоге будет никто толком не знает. Точнее, пока допустип, 5 млн в день, а потом может и на порядок больше. И возможны варианты вроде того что таблица будет бэкапироваться и очищаться, например, раз в месяц. В общем, решение ищется чтобы получить требуемую производительность.
В принципе, данные не отличаются принципиально от тех что будут в итоге, лишь с той разницей что поля tm и rday, rmonth, etc. у них ограничены узким интервалом времен, а в реале диапазон будет зависеть от условий эксплуатации.

Кстати, вот в том числе поэтому пока невозможно адекватно оценить итоговую селективность по этим полям...

"Я вот занимаюсь оптимизацией лишь тогда, когда это действительно нужно"... В том то и дело, что проблема уже на этапе нагрузочного тестирования вылезла - запросы которые должны выполняться раз в час выполняются по 70 мин. Копнул поглубже вопрос, в итоге получается что оптимизировать можно под тестовые данные (в принципе это уже удалось), но как там будет в итоге - хоть правда на отдел эксплуатации этот головняк перекладывай :)

Anton Demidov , "почему VARCHAR (1) вместо CHAR (1)" - так получилось. На самом деле схема БД генерится Torque , это сделано для унификации под разные БД, вот оно почему-то varchar(..)и сделало. Что, сильно может на производительность сыграть?