尝试追赶 - 资源密集度？

我读过使用SQL Server存储过程中的Try Catch块可以播放大量服务器资源。我的问题是它使用了多少资源？尝试追赶 - 资源密集度？

我目前使用Try Catch块和事务，只要我的sproc进行大量数据更改，这对于防止不正确的数据进入数据库以及记录错误非常有用，但是我想使在我所有的sprocs中使用这种编程方法。

如何存在很大差异。它做什么呢？

2013-01-15 JAT

你从哪里读到的？你有链接吗？ –

我已经做了一些测试，在这个 - 见http://www.sqlperformance.com/2012/08/t-sql-queries/error-handling –

我读过一本书回来时，我在大学，虽然不记得确切的名字。它确实有道理，它将需要一些资源来检查错误，但我只是想知道多少。 – JAT

零。使用TRY/CATCH的代码消耗与不使用TRY/CATCH的代码完全相同的资源，唯一的区别是前者通常比后者更正确。事实上TRY/CATCH代码是更高效在错误的存在作为代码流直跳转到catch块，并避免运行在请求/存储过程中的语句的剩余部分仅回滚末。

只是为了记录，我不买一秒钟，写的代码，每个语句是甚至远程后检查@@ ERROR一个可行的选择。

我读过一本书回来时，我在大学

为了确认读数并未提及与try/catch语句的T-SQL代码，而是所指的C++代码或无一例外（JVM或IL）。回到黑暗时代，对于添加异常处理代码是否具有性能影响（是的，它具有）以及我们是否应该考虑这个因素存在争议（不，我们不应该，使用异常处理的代码早已赢得了由于正确性）。但是对于您的观点来说，这种讨论是毫无用处的：运行您的T-SQL的后端引擎会进行异常处理编译，并且您无能为力。再次，这对您的T-SQL代码没有影响。

来源

2013-01-15 14:24:25

谢谢。我喜欢在我的脚本中使用Try Catch，但由于我们处理的交易量很高，我们总是被告知不要使用它。我的逻辑还告诉我，在错误发生后立即结束脚本会更有效，而不必首先查询@@ ERROR。谢谢 – JAT

不知何故相关：http://rusanu.com/2009/06/11/exception-handling-and-nested-transactions/ –

尝试追赶 - 资源密集度？

回答

相关问题