c# - 用于修复 .NET 应用程序以解决 SQL Server 超时问题并缩短执行时间的清单

Question

用于改进 .NET 代码和 SQL Server 之间执行时间的清单。从基本到奇怪的解决方案的任何东西都值得赞赏。

代码：

通过avgbody更改命令和连接中的默认超时。

使用存储过程调用而不是avgbody的内联 sql 语句。

使用Jay Shepherd的活动监视器查找阻塞/锁定。

SQL 服务器：

注意AlexCuse在存储过程中的参数嗅探。

谨防Martin Clarke的动态增长数据库。

使用 Profiler 查找BradO 耗时超过100 毫秒的任何查询/存储过程。

通过avgbody增加事务超时。

通过avgbody将动态存储过程转换为静态存储过程。

查看Jay Shepherd的服务器有多忙。

score 5 · Accepted Answer

在过去，我的一些解决方案是：

修复 sql 命令的默认超时设置：

将 myCommand 调暗为新 SqlCommand("[dbo].[spSetUserPreferences]", myConnection)

myCommand.CommandType = CommandType.StoredProcedure

myCommand.CommandTimeout = 120
增加连接超时字符串：

Data Source=mydatabase;Initial Catalog=Match;Persist Security Info=True;User ID=User;Password=password; 连接超时=120
在 sql-server 2005 中增加事务超时

在管理工作室的工具 > 选项 > 设计器中增加“事务超时时间：”即使“覆盖表设计器更新的连接字符串超时值”选中/取消选中。
将动态存储过程转换为静态存储过程
使代码调用存储过程，而不是在代码中编写内联 sql 语句。

score 3 · Accepted Answer

对于响应时间长的抱怨，一个奇怪的“解决方案”是有一个更有趣的进度条。意思是，根据用户的感觉工作。一个示例是 Windows Vista 等待图标。那个快速旋转的圆圈给人的感觉是事情进展得更快。谷歌在 Android 上使用了同样的技巧（至少我见过的版本）。

但是，我建议先尝试解决技术问题，然后仅在您别无选择时才研究人类行为。

score 2 · Accepted Answer

你在使用存储过程吗？如果是这样，您应该注意参数嗅探。在某些情况下，这可能会导致一些非常长时间运行的查询。一些阅读：

score 1 · Accepted Answer

首先也是最重要的 - 检查正在运行的实际查询。我在通过我的程序进行设置时使用 SQL Server Profiler，并尽可能检查我的所有查询是否使用正确的连接和引用键。

score 0 · Accepted Answer

运行 Profiler 以测量查询的执行时间。
检查应用程序日志记录是否存在任何死锁。

score 0 · Accepted Answer

几个快速的...

score 0 · Accepted Answer

我也喜欢使用SQL Server Profiler。我喜欢在工作日中间的 15-30 分钟的时间里，在他们的数据库服务器上的客户端站点上设置跟踪，并记录所有持续时间 > 100 毫秒的查询/存储过程。无论如何，这就是我对“长期运行”查询的标准。

score 0 · Accepted Answer

一种适用于 SQL Server 2000 的奇怪方法，今天可能仍然适用：

确保您没有尝试在生产中动态增长数据库。有一点是，分配额外空间和正常负载运行所需的时间会导致查询超时（以及增长！）

8 回答 8