嘿，这个问题太贴合实际场景了——刚好我之前帮不少处理文件存储的项目踩过类似的坑，给你详细拆解下：

基础情况：未压缩+常规存储 #

首先说最直接的答案：如果你的2MB PDF是直接以未压缩的字节流存入VarBinary(MAX)，那它占用的数据库空间基本就等于文件的实际大小——也就是约2MB（准确来说是2097152字节）。

为什么？因为VarBinary(MAX)是直接存储原始字节数据的，没有额外的格式转换开销，唯一的额外开销是SQL Server用来管理LOB（大对象）数据的少量元数据（比如指向LOB存储区的指针，大概16字节左右），这部分完全可以忽略不计。

影响空间占用的关键因素 #

不过实际场景里还有几个变量会影响最终的空间使用：

• 数据库压缩：如果你的数据库或表开启了页压缩/行压缩，那SQL Server会尝试对LOB数据进行压缩。但要注意：PDF本身已经是压缩格式了，所以这种压缩的收益非常有限，大概率只能减少几个百分点的空间，聊胜于无。
• FILESTREAM 存储：这才是解决你公司数据库空间不足的关键！如果把VarBinary(MAX)和FILESTREAM结合使用，那么文件的实际内容会被存储到文件系统里，而数据库里只保存一个指向该文件的元数据指针（几十字节）。这种情况下，2MB的PDF几乎不会占用数据库的空间，所有文件数据都存在磁盘的独立文件夹里，完美解决数据库空间紧张的问题。
• 行内/行外存储：当VarBinary(MAX)的数据超过8000字节时，SQL Server会自动把数据移到行外的LOB存储区，行里只留指针。但不管是行内还是行外，数据本身的存储空间还是和文件大小一致，只是存储位置不同而已。

给你的实际建议 #

针对你们公司数据库空间不足的情况：

1. 优先考虑启用FILESTREAM，这是最有效的解决方案，既不影响文件的上传下载逻辑（.NET WebForms也能很好支持），又能彻底避免占用数据库空间。
2. 如果暂时没法启用FILESTREAM，那2MB的PDF存储就是约2MB的空间，不用太担心单文件的占用——真正要注意的是累计的文件数量，如果要上传大量PDF，那总占用还是会快速增长。
3. 可以尝试在上传前对PDF进行二次压缩（比如用一些PDF压缩工具），但对于已经是压缩格式的PDF，效果可能不明显，除非是扫描生成的大体积PDF。

内容的提问来源于stack exchange，提问作者Paljilo Domijilo