这个问题来自开发者，所以可能是一个简单的问题。
我们有一个dev和prod sqlservers（2000），我怀疑在Prod服务器上的磁盘写入时间是相当缓慢的。 我已经完成了以下t-sqltesting
testing1：10K插入，开发2秒，产品63秒
if object_id('testD') is not null drop table testD create table testD (i integer) declare @i int set @i=1 while @i <= 10000 begin insert into testD (i) values (@i) set @i = @i+1 end testing2：5k删除，在任一服务器上没有时间
delete from testD where i >= 5000
testing3：嵌套循环，开发2秒，产品5个seecs
select count(Ai + Bi) from testD A , testD B
这些testing是在数小时内完成的，而且我总能得到相同的结果。 我是一名开发人员，所以我只能通过SQLServer访问服务器。 如果有的话，可以从这些testing中得出什么结论，以及我会问技术支持部分是什么样的问题？
每台服务器有什么样的磁盘子系统？ 在不了解服务器的情况下，以及在进行testing的时候发生了什么，现在确实知道问题出在哪里。
起初，它听起来像磁盘子系统有问题，但这可能是误导。
CPU可能正忙于运行压缩备份。 如果磁盘位于SAN上，并且使用与文件服务器共享的存储，则文件服务器可能正在进行夜间碎片整理操作。 SQL Server可能正在重build此数据库中的所有索引，或者服务器上的其他数据库，并且这些操作正在占用所有磁盘资源。
没有更多的访问SQL Server，你将无法找出问题所在。 将问题报告给支持团队，确保他们确实跟进。 如果你的支持团队没有问题，他们应该已经意识到这个问题并进行处理。
生产服务器上还有多less东西？
在您的开发箱中，您可能是唯一活跃的用户，因此可以为您的查询获取所有资源，但是在生产环境中，您可能会在数据库和/或该服务器上可能存在的其他数据库上进行大量活动查询，所以有IO带宽争用。
我提到要仔细看看磁盘或磁盘系统是mdf和ldf文件的碎片。
另一方面，sql-server index-fragmentation可能会降低性能，或者统计信息总是与dev-db上的行数不同，而pred-db上的行数更高。 尝试将您的prod-server的统计信息转移到您的开发服务器以获得相同的执行计划。
最后但并非最不重要的是看看（如何称为）备份级别：如果它是'full'，则eveything进入事务日志（* .ldf），如果是'simple'则不会写入transactionlog。 所以我打赌你的开发系统configuration了简单模式，你的prod系统驱动全模式。
最后，如果您的本地PC上有Management Studio（查询分析器），则通过networking访问服务器。 它可能是你有一个更好的带宽，例如1 GBit到开发服务器，只有100MBit到您的prod服务器。
不要看光在哪里，事实在于黑暗中…
和平
冰