表使用过多的磁盘空间

当我运行“通过桌面的磁盘使用情况”在SQL Server Management Studio报表，它显示了使用有关的磁盘空间1.8GB我的表之一：表使用过多的磁盘空间

enter image description here

表定义：

CREATE TABLE [dbo].[RecipeItems](
    [wo_id] [varchar](50) NOT NULL, 
    [invent_id] [varchar](50) NOT NULL, 
    [invent_dim_id] [varchar](50) NULL, 
    [ratio] [float] NOT NULL 
) ON [PRIMARY]

我倒是大致估计，每行只需要不到200个字节，且仅7K记录，这不应该占用1-2MB比多。但显然，情况并非如此。这张桌子使用这么多存储空间的原因可能是什么？

来源

2012-08-09 Eren Ersönmez

你在这个表上执行过任何大的删除操作吗（例如它是否用来存储大于7K行）？有很多更新吗？你有没有尝试重建表格（应该非常快）？ – 2012-08-09 14:38:20

我还没有尝试重建或收缩数据库。 – 2012-08-09 14:39:18

在这个表上是否有*任何索引（包括主键或唯一键约束）？ – 2012-08-09 14:40:03

很可能是很多数据已被更新或删除。由于它是一个堆更新可以导致转发记录。我会先试试这个：

ALTER TABLE dbo.RecipeItems REBUILD;

接下来我会考虑添加一个聚集索引。

不要运行一个shrink database命令来修复这个表，PLEASE。

当你执行你的“删除所有与批量插入”我会做这种方式，运行在中间的重建：

TRUNCATE TABLE dbo.RecipeItems; 
ALTER TABLE dbo.RecipeItems REBUILD; 
BULK INSERT dbo.RecipeItems FROM ...

如果添加一个聚集索引，你可能想这样做有点不同。如果你不能使用TRUNCATE，显然应该继续使用DELETE。如果表格符合条件，则TRUNCATE将导致更少的日志流失，并且由于您正在清除表并重新填充表，因此您似乎不需要从中恢复。事实上，你可能会考虑每次丢弃表格并重新创建它。

来源

2012-08-09 14:40:04

我们对数据结构知之甚少，无法了解TRUNCATE是否合适，甚至无法正常工作。 – podiluska 2012-08-09 14:48:38

好的，如果TRUNCATE不是一个选项，请继续使用DELETE。这不是我答案的重点。 – 2012-08-09 14:51:25

谢谢。我一直在使用'DELETE RecipeItems'，然后实际上使用'SqlBulkCopy'类从.NET代码进行批量插入（我还没有研究过它如何在底层执行批量更新）。我不做任何更新，所以你仍然推荐REBUILD方法？ – 2012-08-09 14:57:07

表使用过多的磁盘空间

回答

相关问题