用于将 .NET 应用程序修复为 SQL 服务器超时问题并改善执行时间的清单

Question

A checklist for improving execution time between .NET code and SQL Server. Anything from the basic to weird solutions is appreciated.

Code:

Change default timeout in command and connection by avgbody .

Use stored procedure calls instead of inline sql statement by avgbody .

Look for blocking/locking using Activity monitor by Jay Shepherd .

SQL Server:

Watch out for parameter sniffing in stored procedures by AlexCuse .

Beware of dynamically growing the database by Martin Clarke .

Use Profiler to find any queries/stored procedures taking longer then 100 milliseconds by BradO .

Increase transaction timeout by avgbody .

Convert dynamic stored procedures into static ones by avgbody .

Check how busy the server is by Jay Shepherd .

Answer 1

In the past some of my solutions have been:

1. Fix the default time out settings of the sqlcommand:

   Dim myCommand As New SqlCommand("[dbo].[spSetUserPreferences]", myConnection)

   myCommand.CommandType = CommandType.StoredProcedure

   myCommand.CommandTimeout = 120

2. Increase connection timeout string:

   Data Source=mydatabase;Initial Catalog=Match;Persist Security Info=True;User ID=User;Password=password; Connection Timeout=120

3. Increase transaction time-out in sql-server 2005

   In management studio's Tools > Option > Designers Increase the “Transaction time-out after:” even if “Override connection string time-out value for table designer updates” checked/unchecked.

4. Convert dynamic stored procedures into static ones

5. Make the code call a stored procedure instead of writing an inline sql statement in the code.

Answer 2

A weird "solution" for complaints on long response time is to have a more interesting progress bar. Meaning, work on the user's feeling. One example is the Windows Vista wait icon. That fast rotating circle gives the feeling things are going faster. Google uses the same trick on Android (at least the version I've seen).

However, I suggest trying to address the technical problem first, and working on human behavior only when you're out of choices.

Answer 3

Are you using stored procedures? If so you should watch out for parameter sniffing. In certain situations this can make for some very long running queries. Some reading:

http://blogs.msdn.com/queryoptteam/archive/2006/03/31/565991.aspx

http://blogs.msdn.com/khen1234/archive/2005/06/02/424228.aspx

Answer 4

First and foremost - Check the actual query being ran. I use SQL Server Profiler as I setup through my program and check that all my queries are using correct joins and referencing keys when I can.

Answer 5

A few quick ones...

• Check Processor use of server to see if it's just too busy
• Look for blocking/locking going on with the Activity monitor
• Network issues/performance

Answer 6

Run Profiler to measure the execution time of your queries.
Check application logging for any deadlocks.

Answer 7

I like using SQL Server Profiler as well. I like to setup a trace on a client site on their database server for a good 15-30 minute chunk of time in the midst of the business day and log all queries/stored procs with an duration > 100 milliseconds. That's my criteria anyway for "long-running" queries.

Answer 8

Weird one that applied to SQL Server 2000 that might still apply today:

Make sure that you aren't trying to dynamically grow the database in production. There comes a point where the amount of time it takes to allocate that extra space and your normal load running will cause your queries to timeout (and the growth too!)