我们目前在查询sql server程序超时时遇到困难。查询将在5秒内最多运行10次，但有时，proc会继续运行超过2分钟并导致前端超时（.net MVC应用程序）..
他们一直在研究这个问题超过一个星期，检查工作，服务器性能，所有似乎都没问题。
DBA已将其缩小到特定的表格，该表格正在从具有插入/更新的不同应用程序进行轰炸。这与复杂的选择查询相结合，导致超时该表上的连接（我被告知）导致超时..
对于如何绕过这些超时，是否有任何建议？ 即。
答案 0 :(得分：0)
正在被更新轰炸的桌子是一张被锁轰击的桌子。是的，这可能会影响性能。
首先，复制表并多次运行查询。性能问题还有其他可能性。
SQL Server中存储过程性能不稳定的一个原因是编译。存储过程中的代码在第一次执行时进行编译 - 生成的执行计划可能适用于某些输入，而不适用于其他输入。通过使用每次重新编译查询的选项可以很容易地解决这个问题（尽管这增加了开销）。
然后，考虑一下查询。它需要最新的数据吗？如果没有，也许你可以每小时或每天复制一次表。
如果需要最新数据，您可能需要重新考虑架构。使用聚簇标识列执行仅插入的表始终插入表的末尾。这不太可能干扰表上的查询。
复制可能会或可能不会帮助解决问题。毕竟，完全复制将在复制副本上进行更新。你不能解决＃34;轰炸＆＃34;轰炸两张桌子的问题。
如果您的查询涉及大量历史数据，那么分区可能会有所帮助。只有最新的分区才会被轰炸＆＃34;，让其他分区对查询更加敏感。
答案 1 :(得分：0)
DBA已将其缩小到特定的表格，该表格正在从具有插入/更新的不同应用程序进行轰炸。这与复杂的选择查询相结合，导致超时该表上的连接（我被告知）导致超时
我们曾经面临很多时间，并且过去经常会有很多升级。这就是我们为减少超时而采取的方法..
有些可能适用于您的情况，有些可能不适用......但是以下不会造成任何伤害
更改以下sql server设置：
1.远程登录超时：60
2.Remote query timeout：0
此外，如果您的Windows服务器设置为使用动态ram，请尝试将其更改为静态ram ..
您可能还需要调整一些Windows服务器设置
TCP Offloading/Chimney & RSS…What is it and should I disable it?
按照上述步骤，将时间缩短了99％..
其余1％，我们已分别处理每个案件
1.更新查询中涉及的那些表的统计信息 2.尝试进一步微调查询
这有助于我们减少超时......