Здравствуйте, Scrambler, Вы писали:

S>О, всезнающий All,

S>Есть MSSQL 2008, на нем база, в ней таблица. В нее пишется информация о различных событиях с интервалом в час.
S>Структура примерно такая:

S>id int, dimension1 int, dimension2 int, dimension3 int, timerecorded datetime, <разные полезные данные по event'у>

S>Комбинация dimension1, dimension2, dimension3, timerecorded всегда уникальна.
S>В пределах же комбинации dimension1, dimension2, dimension3 находится серия записей о событиях. Этакая эмуляция куба.
S>Наиболее частая выборка — как раз получить значения из dimension1, dimension2, dimension3 за какой-то период времени.

S>Я сделал clustered index на dimension1, dimension2, dimension3 и простой индекс на timerecorded. Это вообще жизнеспособно?
S>После внедрения такой структуры все стало работать очень быстро (в таблице около 500 млн. записей).
S>Через неделю (добавляется около 10000 записей в час) появились проблемы с быстродействием. Причину пока не выяснил, но есть подозрения, что это из-за моей модификации.


Быстро стало работать скорее всего из-за индекса по timerecorded.

Кластерный индекс у вас по идее там должен быть по ID, по dimension1..N делать его ну совсем не надо. И вы точно уверены, что индекс именно кластерный и именно по dimension1,2,3?

Потом, какого рода проблемы появились? при каких запросах, каков план?

Потом, ссылки на строки вам часто нужны, например, join с ней по id и подобное? Если нет — то кластерный индекс нужен как раз по времени