更改表以更改数据类型导致非常大的数据库文件答案

【问题标题】：Alter table to change datatype causing very large database file更改表以更改数据类型导致非常大的数据库文件
【发布时间】：2012-03-30 09:31:44
【问题描述】：

我正在开发一个大约 6Gb 的数据库。我需要将所有非 unicode 列转换为 unicode，例如将所有 varchar 更改为 nvarchar。

我使用像ALTER TABLE mytable ALTER COLUMN mycolumn nvarchar(...) 这样的 ALTER 语句编写了这个脚本，但后来我发现数据库大小大幅增加。 .mdf 文件增长到超过 70Gb，这让我感到惊讶。我知道 unicode 占用的空间是 varchar 的 x2 倍，但即使数据库全是 varchar 并且已转换，我希望它的最大大小为 12Gb。

我试图缩小数据库和文件以查看它是否是未分配的空间，但这几乎没有效果，sp_spaceused 表示没有过多的未分配空间。

有谁知道为什么数据库会变得如此之大？我很想知道是什么原因造成的。

我已经设法将列数据类型更改为 unicode，方法是创建一个从旧数据库编写脚本的新数据库并导入所有数据，结果只是增加了 1Gb 的大小，所以我想了解为什么要更改列数据类型导致了这种增长。

【问题讨论】：

标签： sql-server database data-conversion

【解决方案1】：

您是否检查过增加的大小是否在日志文件中？如果这是问题所在，请通过备份您的数据库来截断它。这是最有可能的问题。

【讨论】：

感谢 JotaBe 的回复，很遗憾没有，是 .mdf 文件而不是 .ldf 文件越来越大。
检查表是否有低填充因子的聚集索引。尝试在一些较大的中制作 DBCC DBREINDEX 并查看结果。如果您的 nvarchar 非常大，并且填充因子较低，则可以为表保留大量空闲空间。这仅适用于聚集索引。
你是对的 JotaBe...它是日志文件！我在还原数据库时犯了一个错误，并将日志文件放在数据文件应该所在的目录中，并将数据文件放在日志目录中。所以这就解释了，我混淆了这两个文件。非常感谢您的帮助。

【解决方案2】：

嗯，这样的增加肯定会产生很大的开销。 SQL 可能会在内部对列进行复制以增加它。但是70gb确实太大了

另外，您说的是 70 GB 的已分配数据大小还是实际数据大小？因为有区别。检查数据库文件的自动增长属性，如果它设置为几 GB 或很大的百分比，那就可以解释了

【讨论】：

感谢迭戈。我检查了一下，但自动增长是 10MB，但我在数据和日志文件上犯了一个错误，正是这种混乱让我相信是数据文件在增长，而不是日志文件。