SQL Server导入大SQL文件后MDF文件远小于预期的技术问询

这种情况可能是正常的，也可能存在潜在异常，具体取决于你的数据特性、SQL语句和SQL Server配置，以下是关键排查方向：

一、正常场景的常见原因 #

1. 数据压缩生效 #

SQL Server的行压缩/页压缩会大幅减少重复数据的存储空间。如果你的表开启了压缩（默认新建表不会开启，但手动设置或某些模板会启用），原始SQL文件里的大量重复值会被压缩，最终数据文件（MDF）体积远小于SQL文件大小。
可以通过以下查询查看表的压缩配置：

SELECT 
    t.name AS 表名,
    p.data_compression_desc AS 压缩类型
FROM sys.tables t
JOIN sys.partitions p ON t.object_id = p.object_id
WHERE p.index_id IN (0,1); -- 仅查看堆表或聚集索引对应的分区

2. 重复数据被约束过滤 #

如果你的表设置了主键、唯一约束或唯一索引，SQL文件中重复的INSERT语句会被自动忽略，实际写入的有效数据量远小于SQL文件的总大小。比如SQL文件里重复插入同一行数据，最终只有一行会被保留。
可以统计表的实际行数，和SQL文件中的INSERT行数对比：

SELECT COUNT(*) FROM [你的目标表名];

3. 数据本身的冗余度低 #

SQL文件是明文的SQL语句，包含INSERT INTO (...) VALUES (...)这类重复语法，而SQL Server存储的是格式化后的数据，本身就会比明文SQL体积小。如果你的数据字段本身长度短、重复值多，这种差距会更明显。

二、异常场景的排查方向 #

1. 脚本未完全执行 #

即使没有显性报错，也可能存在个别批次的INSERT因为约束冲突、语法问题被静默跳过（比如SET XACT_ABORT OFF时，单条插入失败不会终止整个脚本），导致实际写入的数据量远低于预期。

• 执行脚本后查看@@ROWCOUNT变量，获取总插入行数；
• 查看SQL Server的错误日志，检查是否有隐藏的警告或错误信息。

2. 磁盘使用率低的深层原因 #

NVME SSD的IO性能远高于机械硬盘，此时SQL Server的瓶颈可能不在磁盘，而是CPU、内存或锁等待：

• 大量并发INSERT可能导致锁竞争，使数据库无法充分利用磁盘IO；
• 内存不足时，SQL Server会频繁读写缓冲池，但NVME的高IO能力会让磁盘使用率看起来很低；
• 可以通过SQL Server的“活动监视器”查看等待类型，若LCK_M_*（锁等待）或CPU等待占比高，说明瓶颈不在磁盘。

总结 #

优先排查数据压缩、重复数据过滤这两个正常因素，对比实际插入行数和SQL文件的预期行数；若确认数据应该远大于6.5GB，再检查脚本执行完整性和数据库等待状态。

内容的提问来源于stack exchange，提问作者Mustafa Yılmaz