рефакторинг хранимой процедуры

Question

У меня есть хранимая процедура, в настоящее время выполняющая сложную выборку, которая часто истекает при использовании. Предложенное решение в моем отделе состояло в том, чтобы просто увеличить продолжительность времени ожидания; что я действительно не хочу делать. Я хотел бы провести рефакторинг этого sproc, но поскольку он настолько сложный и недокументированный (унаследованные системы), я обеспокоен тем, что мой рефакторинг не приведет к выполнению той же функциональности, которая будет выполняться более эффективно. Есть ли какие-либо стратегии, которые нужно использовать при рефакторинге хранимой процедуры, чтобы гарантировать, что те же функции выполняются за меньшее время?

Это хранимая процедура Microsoft SQL Server 2005.

Answer 1

Я сталкивался с такой ситуацией в прошлом. Лучше всего создать простое приложение на C # или VB .Net. Когда вы реорганизуете sp, дайте ему новое имя. Используйте приложение для вызова старого и нового sp. Затем сравните выходные данные двух sp, чтобы убедиться, что они возвращают одинаковые значения в одинаковом порядке.

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

Кроме того, использование NUnit может помочь упростить эту задачу.

Когда я начал свою текущую позицию, мне дали базу данных, которую нужно было изменить для новой схемы. Это потребовало изменения более 100 SP. Используя приложение, которое я описал, я смог быть уверен, что одна из моих модификаций не нарушила бизнес-правил.

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

Answer 2

Наиболее распространенной причиной неэффективных хранимых процедур, с которыми я столкнулся, является преобладание операций скалярного типа, а не операций на основе множеств. Большинство систем СУБД (Oracle, SQL Server, MySQL и т. Д.) Гораздо более эффективны при выполнении работы с большими наборами данных, а не с единичными операциями, повторяющимися несколько раз. Более эффективно выполнить одну операцию для миллиона строк данных, чем выполнить операцию миллион раз для каждой строки.

После попытки определить эти типы узких мест (обычно сначала обращаются к вызовам функций), я бы посоветовал взглянуть на стратегию индексирования таблиц, на которые вы ссылаетесь. В зависимости от выбранной вами СУБД, у вас могут быть некоторые функции типа мастера, которые могут помочь вам найти правильную структуру индекса на основе образца рабочей нагрузки.

Какую базу данных вы используете? Это может помочь отрегулировать некоторые из моих предложений.

Answer 3

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

Answer 4

Используйте SQL Server Profiler для изучения работы текущего SP; это подчеркнет неэффективность и позволит вам нацеливаться только на эти конкретные области, оставляя при этом более производительные биты в покое. Затем вы можете снова использовать профилировщик на своем исправленном SP для сравнения производительности.

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