Стратегия обработки запросов с переменным временем?

Question

У меня есть типичный сценарий, с которым я борюсь с точки зрения производительности. Пользователь выбирает значение из раскрывающегося списка и нажимает кнопку. Хранимая процедура принимает это значение в качестве входного параметра, выполняет и возвращает результаты в сетку. Только для одного из значений («Все») запрос выполняется примерно 2,5 минуты. Для остальных значений запрос выполняется менее 1 мс.

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

Некоторые из моих собственных мыслей:

• Новая таблица, которая хранит информацию для значения «Все» и генерируется каждую ночь
• Кэширование данных на сервере кеширования

Любая помощь приветствуется.

Спасибо!

Обновление

Немного больше информации:

sp возвращает два набора результатов. Первый - это сводка по группам, а второй - первый набор результатов с разбивкой (примерно 80 000 строк).

Answer 1

Сначала я посмотрю, правильно ли установлены индексы.Использование Query Analyzer и помощника по настройке базы данных - это простой и часто эффективный способ узнать, какие индексы могут помочь.

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

Вы можете прочитать об индексированных представлениях здесь:

http://msdn.microsoft.com/en-us/library/dd171921%28v=sql.100%29.aspx

и прочитать о настройке базы данныхсоветник здесь:

http://msdn.microsoft.com/en-us/library/ms166575.aspx

Кроме того, сколько записей возвращает «Все»?Я видел, как люди зацикливались на сценарии «Все» и раньше, но если он возвращает 1 миллион записей или что-то еще, тогда данные все равно не могут быть использованы человеком ...

Answer 2

Кэширование данных - это хорошо, но .... если SP изначально имеет недостатки, вы можете исправить это, вместо того, чтобы пытаться связать его с кэшированием.

Возможно, вы также захотите (поскольку вы не упомянули здесь) посмотреть количество возвращаемых строк «Все» по сравнению с другими выборками и подумать о ваших индексах.

Также в вашем SP "All" заставляет его запускать другие наборы tsql, как, может быть, в case или if ... или он выполняет тот же код только с другим "WHERE"?

Возможно, просто "ALL" просто возвращает МНОГО записей.Возможно, вы захотите реализовать подкачку и частичный возврат набора данных с помощью ajax ... (вроде как вернуть первые 1000 записей раньше, чтобы они могли отображаться, а также отображать пульсатор на экране, пока возвращается остальная часть набора данных)

Это все варианты ... если количество записей действительно не отличается между ВСЕМ и остальными ... тогда, возможно, это как-то связано с потоком запросов / индекса / программы.