Сохранение / кэширование результатов хранимой процедуры для лучшей производительности? (SQL Server 2005)

Question

У меня есть SP, который работал на моих 2 человек сейчас, который все еще занимает 2 минуты или более для запуска. Есть ли способ их предварительно запустить и сохранить в кеше или где-то еще, чтобы, когда моему клиенту нужно просмотреть эти данные в веб-браузере, он не захотел повесить себя или меня?

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

Answer 1

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

Но я бы еще раз взглянул на процедуру, посмотрел план выполнения и увидел, где он медленный, чтобы убедиться, что он не выполняет полное сканирование таблицы.

Answer 2

Предпочтительные решения в следующем порядке:

1. Анализировать запрос и соответственно оптимизировать
2. Кэшируйте его в приложении (вы можете использовать httpRuntime.Cache (даже если не приложение asp.net)
3. Кэширование SPROC приводит к созданию таблицы в БД, а затем добавляет триггеры для аннулирования кэша (удаления таблицы), поэтому при вызове к SPROC сначала проверяется, есть ли какие-либо данные в таблице кеша. Если нет, запустите SPROC и сохраните результат в таблице кеша, если это так, верните данные из этой таблицы. Триггеры в «исходных» таблицах для SPROC просто удаляют * из CacheTable, чтобы «очистить кеш» (в зависимости от того, что делает sproc и его зависимостей, вы можете даже частично обновить таблицу кеша на основе триггера , но все это быстро становится трудно поддерживать ... но иногда вы должны делать то, что должны ... Этот подход позволит кеш-таблице обновляться по мере необходимости. У вас всегда будут самые последние данные, а SPROC будет только запускать при необходимости.

Answer 3

Попробуйте «Анализировать запрос в помощнике по настройке ядра СУБД» из меню «Запрос». Я обычно пишу процедуру в новом окне, вынимаю часть определения запроса и пробую разные комбинации временных таблиц, обычных таблиц и табличных переменных.

Answer 4

ОК, обо всем по порядку, индексы:

• Какие индексы у вас есть в таблицах и использует ли их план выполнения?
• Есть ли у вас индексы по всем полям внешнего ключа?

Во-вторых, использует ли прок один из следующих убийц производительности:

• курсор
• подзапрос
• пользовательская функция
• выберите *
• критерий поиска, начинающийся с подстановочного знака

третий

• Можно ли переписать условие where, чтобы оно было sargeable ? Существует более одного способа написать почти все, и некоторые из них более эффективны, чем другие.

Предлагаю купить разработчикам несколько книг по настройке производительности.

Вероятно, ваш процесс может быть исправлен, но, не видя код, трудно догадаться, в чем проблема.

Answer 5

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