Olg*_*aya 4 index sql-server-2005
我检查了我的巨大数据库并运行了 5 或 7 次收缩任务。我有大约 11 GB 的可用空间。此 DB 用于离线报告操作。之前，当我们创建报告时，它会增长大约 2 或 3 GB（这也很奇怪，但导入和处理了大约 6 百万行 CDR 日志）但上次我们尝试过。即使可用空间约为 11 GB。无法生成报告。磁盘空间意外为空。
因此，进行一些搜索并查看一些建议以检查索引。根据索引碎片，可能存在一些磁盘空间问题。
首先; 索引碎片是否会导致磁盘空间使用效率低下？第二; 如果我让索引重新组织或重建会发生什么？当然，总是有数据库崩溃的风险，但这对数据库有害吗？
有两种不同类型的碎片需要担心：物理碎片和逻辑碎片。物理碎片意味着存储索引的文件在文件系统级别被碎片化。逻辑碎片意味着在索引中插入或更新数据时发生了页面拆分。顺便说一句，如果（当）您的数据库文件被迫增长以容纳更多数据并且增长所需的空间与现有数据文件不连续时，缩小数据库文件最终将导致物理碎片。此外，除非在 tempdb 中执行排序，否则重新组织和重建索引很可能会导致包含索引的文件增长。这可能会进一步加剧物理碎片问题。这就是为什么缩小数据文件几乎从来都不是一个好主意的原因。他们成长是有原因的，
不幸的是，我不能回答你的第一个问题。我假设逻辑索引碎片不会导致 IO 级别的问题。但是，由于文件系统碎片，物理碎片将表现为随机读取次数的增加。
至于你的第二个问题，索引维护应该没有问题。事实上，您应该已经将索引维护作为日常维护的一部分。需要注意的重要一点是，索引重建会通过完整扫描隐式更新您的索引统计信息。但是，索引重组不会。作为我的索引维护的一部分，我明确地对我重新组织的索引执行完整扫描统计更新，而不是重建。
最后，我怀疑您的问题是由索引引起的。在运行此报告之前，您似乎要将大量数据加载到临时表或临时表中。如果您正在加载到临时表，也许您可以将临时表移动到另一个存储卷上的自己的文件组。如果您正在加载到临时表中，您可能会遇到 tempdb 空间不足的情况。无论哪种方式，您似乎都需要额外的存储空间或不同存储介质上的新文件组用于临时表。
希望这个（不可否认太长）答案有帮助！
马特