高度碎片化是一个问题吗？

Question

DBCC SHOWCONTIG scanning 'MyTable' table...
Table: 'MyTable' (2048062382); index ID: 1, database ID: 28
TABLE level scan performed.
- Pages Scanned................................: 1019182
- Extents Scanned..............................: 127400
- Extent Switches..............................: 127399
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 100.00% [127398:127400]
- Logical Scan Fragmentation ..................: 0.01%
- Extent Scan Fragmentation ...................: 77.25%
- Avg. Bytes Free per Page.....................: 135.7
- Avg. Page Density (full).....................: 98.32%

我读过 Scan Density = 100% 非常好，并且 Logical Scan Fragmentation <1% 也很棒。77% Extent Scan Fragmentation 困扰我，但互联网说忽略它。

我正在分析一个单表执行缓慢的查询。它在第一次执行时运行约 30 秒，然后在第二次和后续执行中运行 200 毫秒。我可以用DBCC DROPCLEANBUFFERS.

High Extent Scan Fragmentation 是重要线索吗？

（如果没有，我可能会添加另一个关于我的单表查询的问题）。

Answer 1

根据我的经验，即使您正在执行全表扫描，范围碎片也不太可能对性能产生太大影响，对于更典型的查询模式，它最多可以忽略不计。这适用于使用适合内存的缓存数据的查询 - 如果数据在内存中并且没有直接从磁盘读取，任何类型的碎片显然都变得毫无意义。

现在，您有一个大于 8 GB 的表，因此范围碎片可能对您的查询有害。如果此查询使用跨 3400 万行的表扫描，并且您得到的最坏结果（仅在第一次执行时！）是 30 秒，那么降低该范围碎片数极不可能有多大帮助。这 30 秒用于将数据加载到内存中，我无法想象改善碎片化程度会给您带来很多好处。如果您有足够的内存来将这个表保存在内存中，也许您应该考虑启动作业或某个后台进程来定期运行查询而不强制用户等待它，确保它在缓存中保持新鲜。

Hekaton 可能适合你。