我们有一些索引碎片大于95％的数据库。 尽我所能说，索引从来没有被重build得less得多。 多年以来
（公平地说，这些表似乎具有自动更新的统计function，公平地说，他正在努力进行备份：每天全天和每小时trx日志。）
当我问到时，DBA说他不愿意重build或重组索引。 当我问到为什么时，他无法真正expression出来。 最终他表示担心潜在的数据丢失。 例如，我们的Great Plains Dynamics会计应用程序使用了其中一个数据库，他似乎对此非常担心。
我不是DBA，但是从我读过的内容来看，他的焦虑似乎让我难以理解。
我不知道下一步该做什么。 build议我应该如何进行？
重build数据库索引不应导致任何数据丢失。 然而，这样做可能会导致性能大幅下降，因为在重build完成之前，重build的索引通常无法使用。 出于这个原因，应该在受影响系统空闲的时候在非工作时间进行。
在数据库pipe理员中，偏执狂是一件好事 – 如果他们担心数据丢失，我会让他们对备份进行适当的testing（将他们恢复到单独的系统并确保数据全部存在），如果他们仍然担心在重build索引之前执行完整备份将是一个合理的预防措施。
重build或碎片整理索引不会有数据丢失的风险。
重新组织索引将花费更less的时间，从SQL服务器减less工作量，因此可以在周末types的实例中完成。 如果你所说的是真的，即使重新组织了从未有过的索引，也可能对服务器造成更大的影响。 重build索引将从SQL服务器上花费大量精力，因为它们被丢弃和重build。 在周末进行重build不值得冒着服务器忙于索引的风险，也不值得为使用它的人提供服务。
我同意voretaq7，如果他担心与索引一起工作，先试着在开发或testing服务器上先看看是如何反应的。