Question

我是一个BI项目的新手，在一周的7天中有6天的大数据处理过夜。我注意到处理时间（以小时为单位）以及年份都在增加，我承诺尽可能地识别并尝试修复它。

我发现的一件事是高水平的索引碎片。根据我的研究，我找到了一种获得报告的方法：

从5％到30％的平均碎裂 - >这可以通过REORGANIZE Index
从30％或更高的平均碎裂 - >这可以通过REBUILD Index

以下是报告代码：

SELECT 'ALTER INDEX [' + ix.name + '] ON [' + s.name + '].[' + t.name + '] ' +
       CASE 
            WHEN ps.avg_fragmentation_in_percent > 30 THEN 'REBUILD' 
            ELSE 'REORGANIZE' 
        END +
       CASE 
            WHEN pc.partition_count > 1 THEN ' PARTITION = ' + cast(ps.partition_number as nvarchar(max)) 
            ELSE '' 
        END
FROM   sys.indexes AS ix 
        INNER JOIN sys.tables t ON (t.object_id = ix.object_id)
        INNER JOIN sys.schemas s ON (t.schema_id = s.schema_id)
        INNER JOIN ( SELECT object_id, 
                            index_id, 
                            avg_fragmentation_in_percent, 
                            partition_number
                     FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL, NULL)
                    ) ps ON (t.object_id = ps.object_id AND ix.index_id = ps.index_id)
        INNER JOIN ( SELECT object_id,
                            index_id,
                            COUNT(DISTINCT partition_number) AS partition_count
                     FROM sys.partitions
                     GROUP BY object_id, index_id
                    ) pc ON ( t.object_id = pc.object_id AND ix.index_id = pc.index_id)
WHERE  ps.avg_fragmentation_in_percent > 10 AND
       ix.name IS NOT NULL

本周早些时候我运行报告并获得了32个零散的索引：9个重新创建; 23到REBUILD。我每天都采取纠正措施，得到一份新的报告，今天我得到了26个零散的索引：8个重新组合; 18到REBUILD。

问题：问题非常明显。我不想继续进行纠正性维护，只是要预防并避免夜间产生的碎片。如何避免索引碎片化？任何建议，建议，策略？

一般信息：

每个FK都有一个非聚集索引。
作为常见连接条件一部分的有趣列（无FK）与非聚集索引相关联。
Microsoft SQL Server 2005 - 9.00.5294.00（X64）

提前致谢，

Answer 1

许多事情导致索引defrags：

更改行中索引字段的值
无序添加密钥
可能是dba.stackexchange.com最佳来源的其他东西

根据我的经验，最差的是第一个：更改索引列的值。

您应该设置每晚运行的维护计划来重组索引。您可以使用SSMS执行此操作： SSMS Maintenance Plan

您可以将其作为备份的一部分。它应该在你的隔夜处理后运行，以修复似乎造成的碎片整理。这是我在所有生产数据库上设置的内容。

如何避免datawarehosue数据库中的索引碎片？

1 个答案: