Hat jemand irgendeine Leistungssteigerung/tradoff der Verwendung von BEGIN TRY..END TRY in Sql Server 2008, vs der alten IF @@ ERROR <> 0 gefunden? Nur neugierig zu wissen, ob es Leistungsstrafen gibt oder nicht.SQLServer versuchen fangen Leistung
Dies ist eine alte Frage, aber im Jahr 2012 Aaron Bertrand schrieb einen ausführlichen Artikel Performance impact of different error handling techniques wo er wenige Ansätze verglichen mit Ausnahmen in SQL Server zu tun, und ich dachte, es ist Erwähnenswert ist es hier.
Er sagt, dass die primäre mit Ausnahmen Menschen nutzen zu beschäftigen Ansätze sind:
- Lassen Sie einfach den Motor damit umgehen, und Blase an den Aufrufer eine Ausnahme zurück.
- Verwenden Sie
BEGIN TRANSACTIONundROLLBACKwenn@@ERROR <> 0.- Verwenden Sie
TRY/CATCHmitROLLBACKim BlockCATCH(SQL Server 2005+).Und viele nehmen den Ansatz, die sie überprüfen sollten, wenn sie zuerst die Verletzung fahren entstehen, da es sauberer scheint die zu duplizieren selbst zu behandeln als den Motor zu zwingen, es zu tun.
Seine Schlussfolgerungen sind:
Wenn wir denken, dass wir eine hohe Ausfallrate haben werden, oder haben keine Ahnung, was unsere potenziellen Ausfallrate sein wird, dann zuerst Kontrolle Verletzungen vermeiden in der Maschine wird unser währenddessen enorm wert sein. Selbst in dem Fall, in dem wir jedes Mal eine erfolgreiche Einfügung haben, sind die Kosten für die erste Überprüfung geringfügig und leicht durch die möglichen Kosten der späteren Handhabung zu rechtfertigen (es sei denn, Ihre voraussichtliche Fehlerrate von ist genau 0%).
Das ist der Plan aus dem Artikel:
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`
Seit SQL 2005 sollten Sie versuchen, den TRY CATCH-Weg zu verwenden, um die Ausnahmen zu behandeln oder die Fehler zu protokollieren. Es gilt als Best Practice. Es sollte keine größeren Leistungseinbußen bei der Verwendung geben.
BEGIN TRY
BEGIN TRANSACTION
-- SQL
COMMIT TRANSACTION
END TRY
BEGIN CATCH
ROLLBACK
SELECT
ERROR_MESSAGE(),
ERROR_NUMBER() -- etc
END CATCH
Er über die relative Leistung gefragt ... –
Da die Probleme mit der Datenträgerfestplatte identisch sind, sollten keine nennenswerten Leistungsprobleme auftreten.
Die Leistung von 'TRY ... CATCH' und' IF @@ ERROR <> 0' ist etwas anders. Aber, noch wichtiger, es gibt einen signifikanten Unterschied, wenn Sie versuchen, den Fehler an erster Stelle zu verhindern. Aaron Bertrand hat es in einem ausführlichen Artikel [Leistungseinfluss verschiedener Fehlerbehandlungstechniken] gezeigt (http://sqlperformance.com/2012/08/t-sql-queries/error-handling). Ich füge die Antwort unter die Zusammenfassung seiner Ergebnisse ein. –
Vergessen Sie die Leistung, es ist ein verdammter Anblick sicherer, besser und besser vorhersagbar.
Allerdings erfordert die Verwendung von @@ ERROR normalerweise ein GOTO und/oder viele IF-Anweisungen, um es richtig zu verwalten, also würde ich vermuten, dass es einen kleinen Schub in TRY..CATCH geben könnte.
Einverstanden. Die Leistung ist hier nicht das Hauptanliegen, wenn man bedenkt, wie viel besser ein Konstrukt das T-SQL "TRY"/"CATCH" nach jeder Anweisung für "@@ ERROR" überprüfte. Während bei der Verwendung von "TRY"/"CATCH" ein leichter Leistungseinbruch auftritt, ist es angesichts der anderen Vorteile ein akzeptabler Preis. –
@srutzky, noch, wenn Sie nach der Leistung sind, beachten Sie, dass die Leistung von "TRY ... CATCH" und "IF @@ ERROR <> 0" etwas anders ist. Aber, noch wichtiger, es gibt einen signifikanten Unterschied, wenn Sie versuchen, den Fehler an erster Stelle zu verhindern. Aaron Bertrand hat es in einem ausführlichen Artikel [Leistungseinfluss verschiedener Fehlerbehandlungstechniken] gezeigt (http://sqlperformance.com/2012/08/t-sql-queries/error-handling). Ich füge die Antwort unter die Zusammenfassung seiner Ergebnisse ein. –
@VladimirBaranov Dieser Artikel ist in dieser Frage nicht relevant. Natürlich gibt es erhebliche Einsparungen bei der Vermeidung von Rollbacks. Das ist vorausgesetzt und sollte nicht angegeben werden. Aber Sie brauchen immer noch eine Fehlerbehandlung, und 'TRY ... CATCH' ist viel besser als das Testen von' @@ ERROR <> 0', auch wenn 'TRY ... CATCH' ein bisschen langsamer ist. –
Die Leistung von TRY ... CATCH ist höchstwahrscheinlich etwas höher, wenn keine Fehler auftreten. Auf der anderen Seite wird es in vielen Fällen, in denen ein Fehler vorliegt, schneller sein.
Aber Sie sollten nicht unbedingt für Leistung auf jeden Fall Code. Und der Overhead, wenn überhaupt, wird ziemlich klein sein, so würde ich in diesem Fall nicht die sicherere Syntax für die Leistung eintauschen.
Darüber hinaus macht der Try ... Catch Code ein wenig einfacher zu pflegen, vor allem, wenn Ihr SQL-Entwickler-Team nicht sehr lange um SQL Server war, was leider ein bisschen zu oft passiert. Ich kann mir vorstellen, dass dies in einigen Jahren der Fall sein wird.
Er fragte speziell nach SQL Server; C# -Artikel sind hier nicht relevant. – TheBlueSky
Hey da. Ich bin unsicher, was Ihr Hauptpunkt ist. Wenn Sie vorschlagen, dass zusätzlich zu TRY ... CATCH auch zuerst Kontrollen durchgeführt werden, dann ist dies irrelevant, da es sich auf alle möglichen Szenarien bezieht und zumindest für DB-Profis offensichtlich sein sollte, dass ein einfaches Lesen weniger Arbeit bedeutet als in das Protokoll schreiben und dann mehr Arbeit für die Verwaltung des ROLLBACKs erledigen. Wenn Sie sagen, dass Sie nur die Überprüfung durchführen und TRY ... CATCH nicht verwenden, dann ist das ein gefährliches Missverständnis eines Tests, der nicht darauf hinweist, warum wir die Ausnahmebehandlung überhaupt verwenden. –
@srutzky, dieser Artikel vergleicht verschiedene Varianten, nicht nur die in dieser Frage gestellten. Sie können auf der Chart-Leistung von "TRY ... CATCH" vs 'IF @@ ERROR <> 0' sehen. Bei vielen Rollbacks ist "TRY ... CATCH" viel besser, nicht schlechter, als Sie dachten. –
Dieser Artikel ist meist sinnlos. Es widerspricht wirklich nur dem absurden Szenario, keine Vorvalidierung durchzuführen. Also ignoriere die "Just *" Tests. Wie viele Operationen sind eine einzelne Zeilenaktion? Wer würde den Fehler in Set-basierten Ansätzen zulassen, wenn der Rollback Minuten dauern kann? Und der Test deckt nicht die tatsächliche Verwendung von "TRY ... CATCH" ab, indem die "IF EXISTS" darin platziert werden. Das "All Fail" -Szenario ist interessant zu beachten, aber unpraktisch, weil es nie passieren würde, und es überspringt alle 3 Optionen, also vergleicht man sie nicht. Das zeigt, dass "TRY ... CATCH" in den 6 Tests, die sich hier beziehen, der 3. Platz ist. –