EF Core获取Varbinary类型数据耗时过长问题求助

碰到这种二进制数据加载慢的问题太常见了，我给你梳理几个实用的解决方案，不用急着直接迁到文件系统或Blob存储：

首先得明白为啥SQL查询快但ORM加载慢：本质是内存序列化与数据传输的额外开销——ORM需要把从SQL拿到的二进制流转换成byte[]对象，当你一次性加载80条每条100KB的数据时，这个序列化+内存分配的过程耗时会远超SQL查询本身。

1. 按需加载二进制数据（最推荐的轻量方案） #

核心思路是默认不加载BinaryContent，只在真正需要的时候再查，避免一次性把所有二进制数据塞进内存。

方式一：投影查询获取元数据 #

平时查询只加载Attachment的基础信息（文件名、ID等），不碰二进制列：

var profileWithAttachmentMeta = await _context.Profiles
    .Include(x => x.Attachments.Select(a => new { a.ID, a.FileName, a.ProfileId }))
    .Where(x => x.ID == profileId)
    .ToListAsync();

当需要某个附件的二进制内容时，再单独发起查询：

var targetAttachmentContent = await _context.Attachments
    .Where(a => a.ID == targetAttachmentId)
    .Select(a => a.BinaryContent)
    .FirstOrDefaultAsync();

方式二：手动实现延迟加载 #

如果想保持模型属性的一致性，可以给BinaryContent加延迟加载逻辑（记得关闭EF的自动跟踪或者用单独的上下文实例）：

public class Attachment {
    public int ID { get; set; }
    public int ProfileId { get; set; }
    public Profile Profile { get; set; }
    public string FileName { get; set; }
    
    private byte[] _binaryContent;
    public byte[] BinaryContent 
    { 
        get 
        {
            if (_binaryContent == null && ID != 0)
            {
                using var context = new YourDbContext();
                _binaryContent = context.Attachments
                    .Where(a => a.ID == ID)
                    .Select(a => a.BinaryContent)
                    .FirstOrDefault();
            }
            return _binaryContent;
        }
        set => _binaryContent = value;
    }
}

2. 关闭EF的跟踪功能减少开销 #

如果查询到的数据只是用来展示，不需要后续修改，用AsNoTracking()可以去掉EF对实体的状态跟踪，减少内存占用和序列化开销：

var profileWithAttachments = await _context.Profiles.AsNoTracking()
    .Include(x => x.Attachments)
    .Where(x => x.ID == profileId)
    .ToListAsync();

3. 用流式读取替代一次性加载 #

ORM默认会把二进制数据一次性转换成byte[]，你可以直接用ADO.NET的流式读取来优化，避免一次性占用大量内存：

using var command = _context.Database.GetDbConnection().CreateCommand();
command.CommandText = @"
SELECT p.ID, p.FirstName, p.LastName, 
       a.ID, a.ProfileId, a.FileName, a.BinaryContent
FROM Profiles p
JOIN Attachments a ON p.ID = a.ProfileId
WHERE p.ID = @ProfileId";
command.Parameters.Add(new SqlParameter("@ProfileId", profileId));

await _context.Database.OpenConnectionAsync();
using var reader = await command.ExecuteReaderAsync();

var profileMap = new Dictionary<int, Profile>();
while (await reader.ReadAsync())
{
    var currentProfileId = reader.GetInt32(0);
    if (!profileMap.TryGetValue(currentProfileId, out var profile))
    {
        profile = new Profile
        {
            ID = currentProfileId,
            FirstName = reader.GetString(1),
            LastName = reader.GetString(2),
            Attachments = new List<Attachment>()
        };
        profileMap.Add(currentProfileId, profile);
    }

    var attachment = new Attachment
    {
        ID = reader.GetInt32(3),
        ProfileId = currentProfileId,
        FileName = reader.GetString(5),
        // 用流式读取逐步加载二进制数据
        BinaryContent = reader.GetStream(6).ReadAllBytes()
    };
    profile.Attachments.Add(attachment);
}

// 自己实现Stream转byte[]的扩展方法
public static byte[] ReadAllBytes(this Stream stream)
{
    using var ms = new MemoryStream();
    stream.CopyTo(ms);
    return ms.ToArray();
}

4. 数据分离或使用SQL Server FILESTREAM #

如果上面的优化还是不够，可以考虑：

• 拆分二进制列到单独表：新建AttachmentContent表，只存AttachmentId和BinaryContent，默认查询不关联该表，需要时再单独查询。
• 使用SQL Server FILESTREAM：把二进制数据存储在文件系统，但通过SQL接口访问，兼顾数据库的管理能力和文件系统的存储性能，适合中等大小的二进制数据。

最后：是否要迁到文件系统/Blob存储？ #

如果你的二进制数据后续会变大（比如超过1MB），或者查询频率极高，那迁到Blob存储（如Azure Blob、AWS S3）或本地文件系统确实是更长期的优化方案——数据库本身不是为存储大量二进制数据设计的，Blob存储有更好的扩展性、性能和成本优势。但就你当前的100KB每条的数据量，上面的优化方案应该能把加载时间降到可接受的范围。

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