And*_*eed 6 sql sql-server sql-server-2008
我有一个查询,目前在两个物理服务器上运行只需7秒左右.查询相对复杂,因为它连接了几个表并由实体框架构成.我目前正在将数据库迁移到虚拟托管环境,除了这一个查询之外,一切似乎都没问题.查询虚拟托管的SQL Server实例时,查询最初在7秒内运行,但一两个小时后将突然大约需要8分钟.
在慢速状态下查看执行计划时,我发现了意外的全表扫描.如果我重建该表上的索引,它会立即恢复为7秒.但是,在一个小时左右的时间内,它将转为8分钟.
有问题的表几乎没有变化,我经常能够确定它运行良好和运行缓慢之间的零变化.重建索引后,碎片下降到0.02%左右,但在一两个小时内,它会跳到50%-60%之间.
我不确定碎片是否导致问题,但我完全不知道为什么它可能如此迅速地碎片化.谁能解释一下？
您可以看到许多分段技术的差异，并了解哪种技术最适合您的情况。
填充因子也会影响碎片。
该表上的统计信息可能不会更新
您可能是参数嗅探问题的受害者（查询计划已缓存，但不是最优的）。您能否检查这两种情况是否使用相同的查询计划？
您确定这两个查询相同吗？如果不是，有什么区别？
如果您在查询运行良好或运行不佳时将来自sys.dm_db_index_physical_stats的碎片信息打印到屏幕上，我们可能会为您提供更多帮助。
稍后编辑： 使用默认填充因子，当发生页面拆分时，一半行保留在初始页面中，另一半将移动到新页面。
您几乎没有进行任何更改，但页面数量肯定会增加一倍，因此我怀疑由于 53% 的内部碎片，对表中的所有（或几乎所有）行进行了“小更新”。
其他要执行的操作：
UPDATE TableX SET colA = colA WHERE 1=1）让我们随时了解情况。
| 归档时间： |
|
| 查看次数： |
2583 次 |
| 最近记录： |