EF6中多对多关联查询的性能问题排查与优化诉求

我之前也踩过EF6处理多组M:M关联时的性能坑，你遇到的这种生成冗余UNION ALL的问题，本质是EF6在处理多个导航属性的嵌套投影时，会为每个导航属性单独生成关联逻辑再合并结果，直接导致SQL体积暴涨、执行效率暴跌。

先拆解下你的场景：投影里同时加载了Brands（还嵌套了Aliases）和Categories两个多对多导航属性，EF6默认的查询策略会把这几个导航属性的查询拆分开，再用UNION ALL拼接，自然就出现了三次关联Contact表的臃肿SQL。

下面给你几个实用的解决方案，按落地成本排序：

方案一：用Include预加载+内存投影（最易落地） #

EF6的Include可以一次性预加载所有需要的关联数据，之后切换到内存中做投影，这样能让EF生成更简洁的SQL（一次关联所有表，而非多次拆分后合并）。示例代码：

var contacts = query
    .Include(c => c.Brands.Select(b => b.Aliases)) // 预加载Brands及其关联的Aliases
    .Include(c => c.Categories) // 预加载Categories
    .AsEnumerable() // 切换到内存处理投影，避免EF继续生成复杂SQL
    .Select(contact => new Contact 
    { 
        // 这里的字段映射和你原来的逻辑一致
        Brands = contact.Brands.Select(b => new Brand 
        { 
            Id = b.Id, 
            Name = b.Name, 
            Aliases = b.Aliases.Select(a => a.Value).ToList() 
        }).ToList(), 
        Categories = contact.Categories.Select(c => new Category 
        { 
            Id = c.Id, 
            Name = c.Name 
            // 其他需要的字段
        }).ToList()
        // Contact自身的其他字段映射
    })
    .ToList();

⚠️ 注意：一定要确保query已经加了足够的过滤条件（比如Where），避免把全表数据加载到内存，反而引发新的性能问题。

方案二：手写原生SQL+手动分组映射（极致可控） #

如果Include的方式还是达不到性能要求，或者你需要完全掌控SQL结构，可以直接写原生SQL，再通过中间DTO接收结果后手动分组映射到目标实体：

// 先定义一个中间DTO，用来接收SQL查询的扁平结果
public class ContactWithRelationsDto
{
    public int Id { get; set; }
    public string ContactName { get; set; }
    public int? BrandId { get; set; }
    public string BrandName { get; set; }
    public string AliasValue { get; set; }
    public int? CategoryId { get; set; }
    public string CategoryName { get; set; }
    // Contact的其他必要字段
}

// 执行原生SQL并映射
var sql = @"
    SELECT c.Id, c.Name AS ContactName,
           b.Id AS BrandId, b.Name AS BrandName, a.Value AS AliasValue,
           cat.Id AS CategoryId, cat.Name AS CategoryName
    FROM Contacts c
    LEFT JOIN ContactBrand cb ON c.Id = cb.ContactId
    LEFT JOIN Brands b ON cb.BrandId = b.Id
    LEFT JOIN BrandAliases a ON b.Id = a.BrandId
    LEFT JOIN ContactCategory cc ON c.Id = cc.ContactId
    LEFT JOIN Categories cat ON cc.CategoryId = cat.Id
    -- 这里加上你的WHERE过滤条件
";

var contacts = context.Database.SqlQuery<ContactWithRelationsDto>(sql)
    .ToList()
    // 手动分组，把扁平结果合并为嵌套的实体结构
    .GroupBy(x => x.Id)
    .Select(g => new Contact
    {
        Id = g.Key,
        Name = g.First().ContactName,
        Brands = g.Where(x => x.BrandId != null)
            .GroupBy(x => x.BrandId)
            .Select(bg => new Brand
            {
                Id = bg.Key.Value,
                Name = bg.First().BrandName,
                Aliases = bg.Where(a => !string.IsNullOrEmpty(a.AliasValue))
                    .Select(a => a.AliasValue)
                    .ToList()
            }).ToList(),
        Categories = g.Where(x => x.CategoryId != null)
            .Select(x => new Category 
            { 
                Id = x.CategoryId.Value, 
                Name = x.CategoryName 
            })
            .Distinct()
            .ToList()
    })
    .ToList();

这种方式完全避免了EF的自动SQL生成逻辑，性能最优，但需要维护原生SQL，适合对性能要求极高的场景。

方案三：升级到EF Core（长期最优解） #

如果你的项目有升级空间，强烈建议迁移到EF Core。EF Core在处理多导航属性的投影时，生成的SQL会智能合并关联逻辑，几乎不会出现这种冗余的UNION ALL，同时整体查询性能、API设计都比EF6优秀很多。

额外优化建议 #

• 检查数据库索引：多对多关联表（比如ContactBrand、ContactCategory）的联合主键（ContactId+BrandId/CategoryId）一定要创建索引，Brands、Categories的主键也要确保有索引，这能大幅降低关联查询的耗时。
• 拆分查询：如果关联数据量极大，可以拆分查询——先查符合条件的Contact列表，再批量查询对应的Brands和Categories，最后在内存中手动关联，避免单次查询的数据量过大。

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