我最近知道如果我删除一列或修改它获取的 sql 服务器，space at backend所以我需要重新索引并缩小数据库并且我已经完成了它并且我的数据库大小减少到
2.82 至 1.62
所以它同样是明智的，所以现在我很困惑，所以在我的脑海中出现了很多关于这个主题的问题，请帮助我解决这个问题 1. 所以有必要在特定时间间隔后重新创建索引（刷新）
有必要在特定时间后缩小数据库以便性能保持最新吗？
如果以上是，那么我应该在什么特定时间刷新（收缩）我的数据库？
我不知道应该如何解决磁盘间距问题我有 77000 条记录它需要 2.82gb 数据空间这是不可接受的 我有两个表只有一个表nvarchar(max) 所以应该有最小空间数据库任何人都可以帮我解决这个问题提前谢谢
我将为您简化一些事情，因此您可能想阅读我在回答中谈到的事情。
您必须了解的两个概念。分配空间与可用空间。一个数据库的大小可能为 2GB，但它只使用 1GB，因此它分配了 2GB 和 1GB 可用空间。当您缩小数据库时，它会删除可用空间，因此可用空间应该约为 0。不要认为较小的文件大小会更快。随着数据库的增长，它必须再次分配空间。当您缩小文件然后它经常增长时，它无法以连续的方式分配空间。这会造成文件碎片化，进一步减慢您的速度。
对于数据文件（.mdb）文件，这还不错，但随着事务日志的缩小，日志可能会导致虚拟日志文件碎片问题，从而减慢您的速度。因此，简而言之，几乎没有理由按计划缩减数据库。去阅读有关 SQL Server 中的虚拟日志文件的信息，那里有很多关于它的文章。这是一篇关于收缩日志文件以及它为什么不好的好文章。以它为起点。
其次，随着时间的推移，索引会变得支离破碎。这将主要导致SELECT查询性能不佳，但也会影响其他查询。因此，您需要对数据库执行一些索引维护。请参阅此答案以了解如何对索引进行碎片整理。
更新：
那么重建索引的时间并不明确。索引重建在重建期间锁定索引。本质上，他们在此期间处于离线状态。在您的情况下，对于 SQL Server 来说，77 000 行将很快。所以重建索引会消耗服务器资源。如果您有企业版，则可以进行在线索引重建，这不会锁定索引但会占用更多空间。
所以你需要做的是找到一个维护窗口。例如，如果您的系统从 8:00 到 17:00 使用，您可以安排在下班后进行维护重建。使用 SQL Server 代理对此进行安排。链接中的脚本可以自动运行。
你的数据库不大。如果 IO 被拆分到多个磁盘上，我已经看到 SQL 服务器可以处理 750GB 的表而不会感到紧张。任何数据库服务器最慢的部分不是 CPU 或 RAM，而是磁盘的 IO 路径。这是一个很大的话题。回到您的观点，您将数据存储在NVARCHAR(MAX)字段中。我认为这是大文本。因此，在缩小数据库后，您会看到大小为 1.62GB，这意味着数据库中的每一行大约为 1.62/77 000 大或大约 22Kb 大。这似乎是合理的。将表格导出到文本文件并检查您会惊讶的大小，它可能会大于 1,62GB。
如果需要，请随时询问更多细节。