我有两张桌子 - Things和History。假设Things有一列Id作为主键，另一列LastUpdated是某种时间戳值。 LastUpdated列上有一个索引。还有其他专栏，但我认为这不应该有太多相关性。我的ASP.NET MVC Web API应用程序有两个业务工作流程
获取自上次以来更改的内容。运行表单SELECT [Columns] FROM Things WHERE LastUpdated > @LastUpdated的查询。在没有事务或事务范围的连接上触发此查询。
更新特定内容。这发生在两个数据库事务中 - 第一个事务在SELECT上Things Id，UPDATE Things后面Id使用History。第二个事务在TransactionScope表中插入行。这两项交易均使用Read Committed Things隔离级别进行控制。
我正试图通过诸如
之类的场景来标记性能History表环境：我的开发机器（Core i7,8GB）带有Sql Server 2016 LocalDB引擎。
我观察到的是，随着history表中行数的增加，＃1和＃2的性能都会下降。 ＃2是可以理解的，因为它实际上更新了历史表。但是，我很困惑，为什么＃1会显着降低。例如，＃2时间从空数据库的大约10毫秒降低到Things表中250K行的大约65毫秒，而＃1时间从大约10毫秒降低到200毫秒。请注意，function getTargetOrigin()
{
try {
var url = (window.location != window.parent.location) ? document.referrer : document.location.href;
if (url.indexOf('www.myproduction-website.com')!=-1)
return document.location.protocol + '//www.myproduction-website.com'
else //set the alternative target
return document.location.protocol + '//' + url.split('/')[2];
}
catch(e) //falback to production
{
return document.location.protocol + '//www.myproduction-website.com'
}
}
表具有恒定的行数（5000）。我能想到的唯一解释是由于磁盘IO的争用。
我在这儿吗？有没有办法验证这个（比如使用SQL Profiler）？
答案 0 :(得分：0)
我不能花费太多时间来讨论这个问题，但可疑的是，明显的原因是磁盘I / O争用。我将历史表移动到不同机器上的另一个数据库。现在，历史表中的行数停止影响＃1时序，无论历史表中的行数是多少，它都或多或少保持不变（6-7％方差）。