EF中对同一关联实体联用Include与Where子句查询失败

首先看你的问题：原本正常的查询在添加Include(ad => ad.TrackedVehicule)后抛出SqlNullValueException，还生成了查询整张Vehicule表的低效SQL，这确实是EF Core关联查询处理时的典型问题，我帮你拆解一下：

问题根源 #

从你提供的两段SQL对比就能看出核心问题：

• 未加Include时，EF生成的是带过滤的JOIN查询，通过LEFT JOIN Vehicule并在WHERE里筛选RowEnabled=true，逻辑完全正确；
• 加了Include后，EF错误地拆分了查询：先查符合条件的AlertDetail，然后单独执行了一个不带任何过滤的全表查询Vehicule。这直接导致两个问题：
  1. 性能爆炸：全表扫描Vehicule表，数据量大时性能极差；
  2. 空值异常：当AlertDetail的TrackedVehiculeID为NULL时，EF尝试把NULL映射到TrackedVehicule的Int64类型主键，触发SqlNullValueException。

这种情况通常是因为EF Core的查询优化器在处理过滤条件涉及被Include的导航属性时出现了逻辑偏差，把关联过滤和加载逻辑拆分开了。

修复方案 #

给你两个靠谱的解决办法，按需选择：

方案1：用过滤式Include（EF Core 5+适用） #

如果你用的是EF Core 5.0及以上版本，直接在Include后保留过滤逻辑，同时加上空值判断避免映射异常：

context.AlertDetailsDbSet
    .Include(ad => ad.TrackedVehicule)
    .Where(ad => ad.Alert.CompanyId == companyId 
             && ad.TrackedVehicule != null 
             && ad.TrackedVehicule.RowEnabled == true)
    .Take(1000)
    .OrderByDescending(ad => ad.AlertDateTime)

这个写法会让EF生成正确的JOIN查询，同时把过滤条件应用到关联表上，不会再出现全表扫描。

方案2：显式JOIN替代Include（兼容所有版本） #

如果你的EF Core版本较低，或者想完全掌控SQL生成逻辑，直接用显式Join来关联：

context.AlertDetailsDbSet
    // 先关联已过滤的TrackedVehicule
    .Join(
        context.VehiculeDbSet.Where(v => v.RowEnabled == true),
        ad => ad.TrackedVehiculeID,
        v => v.VehiculeID,
        (ad, vehicule) => new { ad, vehicule }
    )
    // 过滤公司ID
    .Where(j => j.ad.Alert.CompanyId == companyId)
    // 选择AlertDetail，EF会自动绑定导航属性
    .Select(j => j.ad)
    .Take(1000)
    .OrderByDescending(ad => ad.AlertDateTime)

这种方式完全避免了EF自动拆分查询的坑，生成的SQL和你之前正常的版本逻辑一致，还能正确加载导航属性。

额外优化建议 #

• 检查AlertDetail表中是否有TrackedVehiculeID为NULL的记录，如果这些记录不需要保留，直接在查询开头加Where(ad => ad.TrackedVehiculeID != null)，从根源避免空值问题；
• 尽量升级到最新的EF Core稳定版，旧版本在关联查询的处理上有不少已知bug，升级后很多问题会自动消失。

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