我现在有一个20GB的数据库。
我已经运行了一些脚本，这些脚本显示了每个表的大小（以及其他非常有用的信息，比如索引内容），最大的表是110万条记录，占用了150MB的数据。我们只有不到50个表，其中大多数表占用的数据不到1MB。
在查看了每个表的大小之后，我不明白为什么在收缩之后数据库的大小不应该是1GB。sqlserver（2005）报告的可用空间量为0%。日志模式设置为简单。在这一点上，我主要担心的是我觉得我有19GB的未使用空间。还有什么我要看的吗？
一般情况下，我不会在意，我会把这个项目变成一个被动的研究项目，除非这种特殊情况要求我们每周做一次备份和恢复，以便将副本放在卫星上（卫星上没有互联网，因此必须手动完成）。我更愿意拷贝1GB（或者即使它降到5GB！）每周超过20GB的数据。
Sp_SpaceUsed报告如下：
Navigator-Production 19184.56 MB 3.02 MB
第二部分：
19640872 KB 19512112 KB 108184 KB 20576 KB
虽然我发现了一些其他脚本（例如这里的两个服务器数据库大小问题中的一个），但它们都报告了上面或下面的相同信息。
我使用的脚本来自sqlteam。以下是标题信息：
* BigTables.sql
* Bill Graziano (SQLTeam.com)
* graz@<email removed>
* v1.11
前几个表显示了这一点（表、行、保留空间、数据、索引、未使用等）：
Activity 1143639 131 MB 89 MB 41768 KB 1648 KB 46% 1%
EventAttendance 883261 90 MB 58 MB 32264 KB 328 KB 54% 0%
Person 113437 31 MB 15 MB 15752 KB 912 KB 103% 3%
HouseholdMember 113443 12 MB 6 MB 5224 KB 432 KB 82% 4%
PostalAddress 48870 8 MB 6 MB 2200 KB 280 KB 36% 3%
其余的桌子不是一样大就是更小。不超过50张桌子。
更新1：
-所有表都使用唯一标识符。通常每行递增1的整数。
我还重新索引了所有内容。
我运行了dbcc shrink命令，并在前后更新了用法。一遍又一遍。我发现一件有趣的事情是，当我重启服务器并确认没有人在使用它时（而且没有运行维护过程，这是一个非常新的应用程序——还不到一周），当我运行shrink时，它时不时地会说些关于数据更改的事情。谷歌得到的有用答案太少，显然不适用（当时是凌晨1点，我把所有人都断开了，所以似乎不可能真的是这样）。数据是通过c代码迁移的，该代码基本上是查看另一台服务器，然后将数据带过来。此时，删除的行数可能不到50k。即使那些排是最大的一排，我也不会超过100米。
当我通过gui进行收缩时，它会报告有0%的可用收缩空间，这表明我已经得到了它认为可以缩小的空间。
更新2：
Sp_SpaceUsed的“活动”产生了这样的结果（这似乎在金钱上是正确的）：
活动1143639 134488 kb 91072 kb 41768 kb 1648 kb
填充因子为90。
所有主键都是int。
这是我用来“更新”的命令：
DBCC更新（0）；
更新3：
根据Edosoft的要求：
图111975 2407773 19262184
似乎图像表认为它是19GB部分。
但我不明白这意味着什么。
是真的19GB还是误传？
更新4：
和一位同事交谈后，我发现这是因为页面的缘故，因为这里的其他人也指出了这种可能性。映像表上的唯一索引是聚集pk。这是我能解决的问题还是我必须处理？
常规脚本显示图像表的大小为6MB。
更新5：
我想我得在进一步研究之后再处理它。这些图像的大小已经调整为每个大约2-5KB，在普通的文件系统上不需要占用太多空间，但在sqlserver上似乎要消耗更多空间。从长远来看，真正的答案可能是将该表分隔到另一个分区或类似的分区中。
最佳答案
尝试此查询：
SELECT object_name(object_id) AS name, rows, total_pages,
total_pages * 8192 / 1024 as [Size(Kb)]
FROM sys.partitions p
INNER JOIN sys.allocation_units a
ON p.partition_id = a.container_id