SQLServer попробуй поймай производительность - PullRequest
Новая
       24

SQLServer попробуй поймай производительность

9 голосов
/ 22 февраля 2009

Кто-нибудь нашел какой-либо прирост производительности / отдачу от использования BEGIN TRY..END TRY в SQL Server 2008, по сравнению со старым IF @@ ERROR <> 0? Просто любопытно узнать, есть ли штрафы за производительность или нет.

Ответы [ 6 ]

4 голосов
/ 22 февраля 2009

Поскольку проблемы попадания диска базы данных идентичны, заметных проблем с производительностью не должно быть.

3 голосов
/ 22 февраля 2009

Начиная с SQL 2005, вы должны попытаться использовать способ TRY CATCH для обработки исключений или регистрации ошибок. Это считается лучшей практикой. При его использовании не должно быть значительного снижения производительности. 

BEGIN TRY
    BEGIN TRANSACTION
    -- SQL 
    COMMIT TRANSACTION
END TRY
BEGIN CATCH
    ROLLBACK
    SELECT
        ERROR_MESSAGE(),
        ERROR_NUMBER() -- etc
END CATCH
2 голосов
/ 13 февраля 2016

Это старый вопрос, но в 2012 году Аарон Бертран написал подробную статью Влияние на производительность различных методов обработки ошибок , где он сравнил несколько подходов к работе с исключениями в SQL Server, и я подумал, что стоит упомянуть это здесь.

Он говорит, что основные подходы, которые люди используют для решения исключений:

  • Просто дайте двигателю справиться с этим и отправьте сообщение об исключении обратно вызывающей стороне.
  • Используйте BEGIN TRANSACTION и ROLLBACK, если @@ERROR <> 0.
  • Используйте TRY/CATCH с ROLLBACK в блоке CATCH (SQL Server 2005 +).

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

Его выводы:

Если мы думаем, что у нас будет высокий процент неудач или нет идея, какова будет наша потенциальная частота отказов, а затем сначала проверить избежать нарушений в двигателе будет очень дорого в то время как. Даже в том случае, если у нас есть успешная вставка каждый раз, стоимость проверки вначале незначительна и легко оправдывается потенциальная стоимость обработки ошибок позже (если вы не ожидали частота отказов составляет ровно 0%).

Это график из статьи:

summary

CheckInsert    |  Checks `IF EXISTS` first  |  Simple `INSERT`
CheckRollback  |  Checks `IF EXISTS` first  |  Use `IF @@ERROR <> 0`
CheckTryCatch  |  Checks `IF EXISTS` first  |  Use `TRY CATCH`
JustInsert     |                            |  Simple `INSERT`
JustRollback   |                            |  Use `IF @@ERROR <> 0`
JustTryCatch   |                            |  Use `TRY CATCH`
1 голос
/ 22 февраля 2009

Забудьте о производительности, это чертовски безопасно, лучше и более предсказуемо.

Однако для использования @@ ERROR обычно требуется GOTO и / или множество операторов IF для правильного управления им, поэтому я предполагаю, что TRY..CATCH может незначительно усилиться.

0 голосов
/ 02 февраля 2010
0 голосов
/ 23 февраля 2009

Производительность TRY ... CATCH, скорее всего, немного больше, когда нет ошибок. С другой стороны, это будет быстрее во многих случаях, когда есть ошибка.

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

Кроме того, Try ... Catch немного облегчает поддержку кода, особенно если ваша команда разработчиков SQL не слишком долго работала с SQL Server, что, к сожалению, происходит слишком часто. Я полагаю, что это будет более справедливо через несколько лет.

...