Question

我仍然在某种程度上学习sql server，最近在存储过程中遇到了一个选择查询，导致c＃中数据集的填充非常缓慢。起初我认为这与.NET有关，但后来发现了一个建议放入存储过程：

设置implicit_transactions off

这似乎可以解决它，但我想知道为什么我也看到了其他选项，如：

当我有存储过程设置只是为了查询要查看的数据时，是否有人知道在哪里可以找到关于每个操作以及什么是安全使用的良好信息。

我应该注意只是停止通常使用/不使用存储过程辩论这些查询是复杂的选择语句，在多种语言的多个程序中使用它是最好的地方。

编辑：我的答案没有最终完全审核所有选项但确实找到了

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

显着加快复杂查询，我并不担心此实例中的脏读。

Answer 1

这是您想要的SQL Server联机丛书（BOL）页面。它解释了可以在会话中使用的所有SET语句。 http://msdn.microsoft.com/en-us/library/ms190356.aspx

Answer 2

哎呀，有人，某个地方正在大火玩耍。

我从未有过必须启用隐式事务的生产场景。我总是在需要时打开事务，并在完成后提交它们。隐式事务的问题是它很容易“泄漏”一个可能导致可怕问题的开放事务。这个设置意味着什么“如果没有交易打开，请在我第一次运行声明时为我打开一个交易，不要担心提交它。”

例如，请看下面的例子：

set implicit_transactions on 
go
select top 10 * from sysobjects

和

set implicit_transactions off 
go
begin tran
select top 10 * from sysobjects

他们都做了完全相同的事情，但是在第二个声明中很明显有人忘了提交交易。如果你将这个设置放在一个不起眼的地方，这可能会非常复杂。

获取所有set语句的文档的最佳位置是旧的可靠sql server books online。它与查询分析器中的一些实验一起通常只需要掌握大多数设置。

我强烈建议您找出谁设置隐式事务，找出他们为什么这样做，并删除设置，如果它不是真的需要。此外，您必须确认使用此设置的人提交其隐式打开的事务。

可能发生的事情是你有一个打开的事务阻塞了你的存储过程中的一些，并且你正在发生超时，引发错误并在代码中处理，当超时发生时存储过程继续运行。我的猜测是延迟通常是30秒。

Answer 3

我认为您需要深入了解您的存储过程。我不认为SET IMPLICIT_TRANSACTIONS真的会加速你的程序，我认为这可能是巧合。

Answer 4

值得一看的一件事是使用分析器从客户端传递到服务器的内容。

我们遇到一个奇怪的情况，ADO连接的默认SET参数导致SP从客户端运行需要很长时间，我们通过查看服务器从客户端接收的确切内容来解析，完成默认的SET参数与从SSMS执行时发送的内容相比。然后，我们使客户端传递与SSMS发送的SET语句相同的SET语句。

这可能偏离轨道但是当SP在服务器上及时执行而不是从客户端执行时，它是一种有用的方法。