我有一个Sql Server数据库有几个行数为零的表，但占用了10 GB的空间。 我可以通过在问题表上右键单击/属性（数据空间很大，介于1和6 GB之间，行计数在这些表上为零）来看到这一点。 我不知道可能是什么原因造成的，因为我认为零行将意味着几乎为零的空间。
有任何想法吗？
重build表上的所有索引，包括聚集索引。 来自联机丛书 ：
重build索引会丢失并重新创build索引。 这将删除碎片，通过基于指定的或现有的填充因子设置压缩页面来回收磁盘空间，并重新排列连续页面中的索引行。
就像是：
ALTER INDEX ALL ON [lc_db_user].[JMS_MESSAGES] REBUILD DBCC SHRINKDATABASE或（更优选的）DBCC SHRINKFILE只有在空间已经从表本身释放时才会执行某些操作。 另外请确保您熟悉与收缩数据库文件相关的问题 。 执行摘要：永远不要使用自动收缩，只在需要的时候收缩文件，并且始终使用完全重新索引来对所有刚分离的索引进行碎片整理。
如果数据库包含许多行数据，那么这些数据已从表中删除，数据库引擎将不会收缩这些文件。 有命令来做到这一点，我将不得不查看它们。
更新：我曾经使用过的是DBCC SHRINKDATABASE，你可以在这里findTechNet的细节
我似乎无法发布截图，但我所做的是右键单击表格，转到属性，然后在“存储”下：
Data space: 2,152.883 MB FileGroup: PRIMARY Index space: 0.063 MB Partition scheme: Row count: 0 Table is partitioned: False Text filegroup: PRIMARY
当我在表上做SELECT *时，我没有得到任何结果。
这里是CREATE脚本（那里有一个图像字段）：
CREATE TABLE [lc_db_usr].[JMS_MESSAGES]( [MESSAGEID] [int] NOT NULL, [DESTINATION] [varchar](150) NOT NULL, [TXID] [int] NULL, [TXOP] [char](1) NULL, [MESSAGEBLOB] [image] NULL, PRIMARY KEY CLUSTERED ( [MESSAGEID] ASC, [DESTINATION] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
这有点奇怪，但工作：
插入一个虚拟列作为表格的第一列，然后保存表格。
最后，删除新列并再次保存表。
现在你肯定会有0个字节的使用。
诺埃尔Paricollo
处理这种问题的另一种方法是使用TRUNCATE TABLE语句：
TRUNCATE TABLE [lc_db_usr].[JMS_MESSAGES]
但是，这只适用于没有被FOREIGN KEY约束引用的表。
有关更多详细信息： http : //msdn.microsoft.com/en-us/library/ms177570.aspx
尝试这个：
alter table table_name rebuild;