sql - SQL Server 中的快速碎片索引

Question

我有一个查询，目前在两台物理服务器上运行，大约需要 7 秒。该查询相对复杂，因为它连接多个表并由 Entity Framework 形成。我目前正在将数据库迁移到虚拟托管环境，除了这一查询之外，一切似乎都正常。当针对虚拟托管的 SQL Server 实例进行查询时，查询最初会在 7 秒内运行，但一两个小时后会突然需要大约 8 分钟。

在慢速状态下查看执行计划，我发现了意外的全表扫描。如果我在该表上重建索引，它会立即恢复到需要 7 秒。然而，在一个小时左右的时间里，它会变成需要 8 分钟。

所讨论的表几乎没有变化，我通常能够确定它运行良好和运行缓慢之间的零变化。重建索引后，碎片率下降到 0.02% 左右，但在一两个小时内就会跃升至 50%-60% 之间。

• 页面填充度 – 52.95%
• 总碎片率 – 54.19%
• 平均行大小 – 338
• 深度 – 3
• 转发的记录 - 0
• 幽灵记录 - 0
• 索引类型 - 聚集索引
• 叶级行 – 134900
• 最大行大小 - 604
• 最小行大小 – 239
• 页数 – 10736
• 分区 ID – 1
• 版本幽灵行 - 0

我不确定是否是碎片导致了这个问题，但我完全不明白为什么碎片会如此之快。谁能解释一下吗？

Answer 1

• 您可以看到 many fragmentation techniques 的差异看看什么最适合您的情况。

• 填充因子也会影响碎片。

• 该表上的统计信息可能不会更新

• 您可能是参数嗅探问题的受害者(查询计划已缓存，但不是最佳的)。你能检查一下是否same query plan两种情况都使用吗？

• 您确定这两个查询相同吗？如果不是，有什么区别？

如果您将来自 sys.dm_db_index_physical_stats 的碎片信息打印屏幕，我们可能会为您提供更多帮助。查询何时运行良好，何时运行不良。

稍后编辑:使用默认填充因子，当发生页面拆分时，一半行保留在初始页面中，另一半将移动到新页面。

你的变化很小，但页数肯定会翻倍，所以我怀疑由于 53% 的内部碎片，对表中的所有(或几乎所有)行进行了“小更新”。

要执行的其他操作:

• 1/发布您的表格结构以供查看会很有用。
• 2/您是否有 CHAR 数据类型的列？
• 3/列出页面中的平均行数(快与慢)
• 4/检查涉及该表的所有存储过程/查询
• 5/添加触发器并记录(在另一个表中？)在您的表上执行的操作(您可能有 UPDATE TableX SET colA = colA WHERE 1=1)

随时通知我们。