1. перестроить индекс, если он создавался давно и часть данных удалялась
2. использовать кластерный индекс, если данные обновляются не часто
3. разбить таблицу на несколько и создать view объединяющую их (select * from .. union all select ....)
4. использовать специализированный сервер (sybase iq )
M>можно как-нибудь ускорить это безобразие? физически данные так организовать в таблице, чтоб они шли по возрастанию даты и сервер это понимал?
mihhon wrote:
> 1. primary key (instId, fieldId, entrydate)
попробуй сделать такой индекс
primary key (entrydate, instId, fieldId)
и удалить остальные. Интересно что будет..
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
.>попробуй сделать такой индекс .>primary key (entrydate, instId, fieldId) .>и удалить остальные. Интересно что будет..
на месте dba, я бы руки оторвал разработчику)
M>select entrydate, instId, fieldId, value
M>from Values
M>where entrydate='2007-07-10'
M>
M>запрос использует индекс на entrydate, возвращает 130000 записей (3Мb), по времени 2..4 минуты M>execution plan показывает, что index seek 0%, bookmark lookup 100% M>можно как-нибудь ускорить это безобразие? M>физически данные так организовать в таблице, чтоб они шли по возрастанию даты и сервер это понимал?
Можно. Для этого нужно добавить выбираемые поля в индекс по entrydate. Предлагаю перестроить primary key index так, чтобы entrydate шла в нем первой.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Можно. Для этого нужно добавить выбираемые поля в индекс по entrydate. Предлагаю перестроить primary key index так, чтобы entrydate шла в нем первой.
перестраивать PK ради одного запроса?
разумеется, если к этой табличке подавляющее число обращений именно в стиле entrydate = N — это сработает
но, думается, что ID-шники неспроста вынесены в начало индекса
Здравствуйте, Niteshade, Вы писали: N>перестраивать PK ради одного запроса?
Мой модуль телепатии и ясновидения показывает 90% вероятность того, что запросы по entrydate преобладают в данной системе N>разумеется, если к этой табличке подавляющее число обращений именно в стиле entrydate = N — это сработает N>но, думается, что ID-шники неспроста вынесены в начало индекса
А вот я думаю, что ID-шники вынесены в начало индекса совершенно случайно
Если неслучайно, то придется держать два индекса.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Niteshade wrote:
> .>попробуй сделать такой индекс > .>primary key (entrydate, instId, fieldId) > .>и удалить остальные. Интересно что будет.. > на месте dba, я бы руки оторвал разработчику)
По правильному у каждого разработчика должна быть своя бд в которой можно играться и никому этим не мешать.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
S>Мой модуль телепатии и ясновидения показывает 90% вероятность того, что запросы по entrydate преобладают в данной системе
модуль дал сбой, основные запросы именно с instId=123 and fieldId=456 and entrydate>d1 and entrydate<d2
временное решение — новый индекс на все поля, а сейчас делаю partitioned view
M>3. разбить таблицу на несколько и создать view объединяющую их (select * from .. union all select ....)
да, решение — partitioned view, insert очень сильно тормозить стал в последнее время
)
