Question

由于某些原因，我的MDF文件是154gigs，但是，我只从平面文件中加载了7 GB的数据。为什么MDF文件比实际源数据大得多？

更多信息：

只有几张表，行数约为2500万。没有大的varchar字段（最大的是300，大多数都小于varchar（50）。不是很宽的表＆lt; 20列。而且，没有大的表被索引。索引的表少于100万行。我不喜欢使用char，只对字符串使用varchar。数据类型不是问题。

原来是日志文件，而不是mdf文件。 MDF文件实际上是24gig，看起来更合理，但仍然很大恕我直言。

更新：

我通过将恢复模型从FULL更改为simple来修复了LDF（日志）文件的问题。这没关系，因为该服务器仅用于内部开发和ETL处理。另外，在更改为SIMPLE之前，我不得不缩小LOG文件。在大多数情况下不建议缩小，但是，这是日志文件从未变得如此之大和如此之快的情况之一。如需进一步阅读，请参阅this

Answer 1

因为MDF分配了154Gb，或者通过各种操作已经增长到154Gb。数据库文件的至少其中的数据大小，但它可以大于任何金额的使用量。

一个显而易见的问题是如何衡量数据库中的数据量？你使用sp_spaceused了吗？你看过sys.allocation_units了吗？你猜到了吗？

如果使用的大小确实是154Gb中的7Gb，那么你应该保持原样。数据库的大小由这个规模的人决定，或者已经增长，并且可能会重新增长。如果您认为增长或预先调整是偶然的，那么前一点仍然适用，您应该保持原样。

如果你绝对肯定的是，过度分配是一个错误，你可以使用negative consequences of shrinking来缩小数据库。

Answer 2

可能有很多原因可能你使用char（5000）而不是varchar（5000），也许你正在使用bigints而不是int，nvarchar当你需要的只是varchar等等。也许你使用了很多对于每个表的索引，这些都将加起来。也许您的自动增长设置是错误的。您确定这是MDF而不是LDF文件吗？

Answer 3

以防这对某人有用，在dba.stackexchange中找到此查询，它使用sys.dm_db_database_page_allocations来计算每个对象的页数，这包括内部存储并为您提供间隔的真实概览由您的数据库使用。

SELECT sch.[name], obj.[name], ISNULL(obj.[type_desc], N'TOTAL:') AS [type_desc],
       COUNT(*) AS [ReservedPages],
       (COUNT(*) * 8) AS [ReservedKB],
       (COUNT(*) * 8) / 1024.0 AS [ReservedMB],
       (COUNT(*) * 8) / 1024.0 / 1024.0 AS [ReservedGB]
FROM sys.dm_db_database_page_allocations(DB_ID(), NULL, NULL, NULL, DEFAULT) pa
INNER JOIN sys.all_objects obj
        ON obj.[object_id] = pa.[object_id]
INNER JOIN sys.schemas sch
        ON sch.[schema_id] = obj.[schema_id]
GROUP BY GROUPING SETS ((sch.[name], obj.[name], obj.[type_desc]), ())
ORDER BY [ReservedPages] DESC;

感谢Solomon Rutzky：

https://dba.stackexchange.com/questions/175649/sum-of-table-sizes-dont-match-with-mdf-size

Answer 4

未启用AUTO SHRINK或初始尺寸设置为较大的值。

MDF文件大小远远大于实际数据

4 个答案: