重建索引

Question

我有Server 2016 SP2标准版和24*7关键环境和数据库大小1.31TB，驱动器上有186 on的空闲空间。我检查数据库在维护计划重建索引还没有开始前一年，大约知道，我知道标准版本是脱机工作。

我能开始重建索引吗？

请给我建议一下我能做些什么.没有任何问题。

Answer 1

没有足够的数据来提出一些建议，但在你的例子中，我会想到以下几点：

1. 如果它在没有重新编制索引的情况下工作了一年，那么对于当前的系统来说，它是否还可以呢？索引是支离破碎的吗？
2. 数据库中数据的实际大小是多少? 1.3TB是总大小，也许有一个500-1000GBs的日志文件？
3. 索引的实际大小(多个小的还是几个大的)？
4. 是否可以构建一个现有碎片索引的碎片副本，然后只删除旧索引？
5. 如果确实需要重建，您可以添加另一个驱动器，在那里扩展数据库(新FG)，并在那里构建新的索引。

Answer 2

您是对的-使用标准版进行索引重新生成是脱机操作(即阻止会话访问其索引(Es)被重建的表)。您真的确定索引需要去碎片化吗？您可以使用此查询检查碎片：

SELECT S.name as 'Schema',
T.name as 'Table',
I.name as 'Index',
DDIPS.avg_fragmentation_in_percent,
DDIPS.page_count
FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL, NULL) AS DDIPS
INNER JOIN sys.tables T on T.object_id = DDIPS.object_id
INNER JOIN sys.schemas S on T.schema_id = S.schema_id
INNER JOIN sys.indexes I ON I.object_id = DDIPS.object_id
AND DDIPS.index_id = I.index_id
WHERE DDIPS.database_id = DB_ID()
and I.name is not null
AND DDIPS.avg_fragmentation_in_percent > 0
ORDER BY DDIPS.avg_fragmentation_in_percent desc

来源：小木屋

在1.3TB DB上，完成上面的诊断查询需要一段时间。您也没有在DB中编写最大的表，(除了其他表外)表的大小影响重建时间。如果所讨论的索引上的碎片小于30%，则可以进行重新组织而不是重新构建。无论SQL服务器版本如何，重新组织总是在线操作。

为了更容易地进行索引重建，您还可以考虑对最大的表进行分区，因为您可以重建各个分区。但是，有许多关于分区的警告，为了更容易地重新构建，我不能推荐它。

最后一件事--你对整理索引的动机是什么？如果是性能调优，重组很少让您“越过终点线”。