MDF 文件大小比实际数据大得多

Question

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

更多信息：

只有几个表，大约有 2500 万行。没有大型 varchar 字段（最大为 300，大多数小于 varchar(50)。不是很宽的表 < 20 列。此外，还没有对大型表建立索引。带有索引的表少于 100 万行。我不知道不使用 char，仅使用 varchar 表示字符串不是问题。

结果是日志文件，而不是 mdf 文件，这看起来更合理，但仍然很大

更新：

我修复了 。通过将恢复模式从 FULL 更改为 simple，可以解决 LDF（日志）文件的问题。这没关系，因为该服务器仅用于内部开发和 ETL 处理。此外，在更改为 SIMPLE 之前，我必须缩小 LOG 文件。在大多数情况下不建议这样做，但是，这是日志文件不应该增长得如此之大和如此之快的情况之一。要进一步阅读，请参阅这个

Answer 1

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

Answer 2

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

一个明显的问题是如何衡量数据库中的数据量？您是否使用过sp_spaceused？您检查过 sys.allocation_units 吗？你猜到了吗？

如果使用的大小确实是 154Gb 中的 7Gb，那么您应该保持原样。数据库的大小是由某人调整到这个大小的，或者已经增长了，并且很可能会增长回来。如果您认为增长或预调整大小是偶然的，那么前一点仍然适用，您应该保持原样。

如果您绝对肯定过度分配是一个错误，则可以使用所有 收缩的负面后果。

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

未启用自动收缩或初始大小设置为较大值。