当我在生产SQL Server上运行的SSMS中运行简单查询（如“从表AselectColumn1，Column2”）时，结果似乎需要非常长的时间（> 45Min）。 如果从连接到生产SQL Server的开发系统的SSMS运行相同的查询，结果会在几秒钟（<60秒）内返回。
有一点我注意到，如果系统刚重启，性能稍微好一点。 很难确定一个时间，因为我已经在重新启动后很快开始慢速运行，但是最多只能运行20分钟，然后开始动作。 此外，只要重新启动SQL服务不能解决问题或提供暂时的性能提升。
服务器规格为：Windows Server 2003企业版SP2 4 X Intel Xeon 3.6GHz – 6GB系统内存主动/主动群集SQL Server 2005 SP2（9.0.3239）
你有没有比较两个服务器的执行计划？ 你有没有尝试在本地查询你的生产服务器，当结果减慢？ 您是否检查过您的生产服务器上是否有任何阻塞或资源等待？
你有多less行回来？
当你在服务器上返回结果时，可能（但不太可能），因为需要在SSMS中显示所有结果，所以服务器上的资源正在匮乏。
在服务器上的SSMS中，进入工具 – >选项 – >查询结果 – > SQL Server->结果到网格。 执行后检查选项丢弃结果
然后打开一个新的查询窗口，按CTRL + D（确保结果输出到网格）并再次运行您的查询。 还需要45分钟吗？
你可以去你的远程服务器属性，并select“连接”节点。 是否有任何“默认连接选项”打勾？
45分钟和60秒？ 这是…不寻常的。 我以前见过45分钟的查询，但从来没有像“从列表中selectcol1”那样简单的事情。 在那段时间里，甚至60秒钟也能检索到数十万条logging。
也就是说，我不知道为什么这样做可能是这样的，但我会查看你的表上的索引，看它们是否合适，或者它们是否存在，然后运行查询优化器以获得它的意见。
可能要在查询中的表上运行UPDATE STATISTICS
我注意到同样的事情，这似乎是一个SSMS问题….
这个语句，从代码运行，在5秒内执行。
ALTER TABLE xxx ADD XID_New BIGINT NOT NULL CONSTRAINT DF_xxx DEFAULT 0
同样的说法，从SSMS运行已经跑了7分钟..
ALTER TABLE xxx ADD XID_New BIGINT NOT NULL CONSTRAINT DF_xxx DEFAULT 0
相同的机器，相同的数据库，相同的代码，一个从C＃项目运行，另一个从SSMS运行，必须有一个错误或SSMS的问题