EF Core与Npgsql中分页查询时Include失效问题解析

在使用Entity Framework Core与Npgsql进行数据库操作时，开发人员可能会遇到一个特殊场景：当使用分页查询（Skip/Take）配合SplitQuery模式时，从第二页开始Include关联数据会意外丢失。这种现象背后隐藏着EF Core分页查询与SplitQuery机制的重要交互原理。

问题现象重现

典型场景是查询包含多对多关联的实体时，例如查询某个相册集合中的照片及其关联标签：

var photos = await context.Photos
    .Where(x => x.PhotosCollections.Any(c => c.CollectionId == id))
    .Include(x => x.PhotosTags).ThenInclude(x => x.Tag)
    .OrderByDescending(x => x.Pinned)
    .ThenByDescending(x => x.Featured)
    .Skip(5).Take(5)
    .AsNoTracking()
    .ToListAsync();

当启用SplitQuery时，第一页数据正常加载关联数据，但从第二页开始关联集合变为空。切换回SingleQuery模式则问题消失。

根本原因分析

这个问题源于SplitQuery的工作机制与分页查询的结合方式：

1. SplitQuery执行原理：EF Core会先执行主查询获取主体实体，然后为每个Include生成单独的查询获取关联数据，最后在内存中组合结果。

2. 非确定性排序的风险：当排序条件不具备唯一性时（如仅按布尔字段Pinned和Featured排序），数据库可能以任意顺序返回结果。不同批次的查询可能获得不一致的数据排序。

3. 分页放大问题：Skip/Take操作基于不稳定的排序结果执行，导致主查询和关联查询可能处理的是完全不同的数据子集，最终关联数据无法正确匹配。

解决方案与实践建议

要解决这个问题，必须确保查询排序具有确定性：

.OrderByDescending(x => x.Pinned)
.ThenByDescending(x => x.Featured)
.ThenBy(x => x.Id)  // 添加唯一键保证排序稳定性

最佳实践包括：

1. 始终保证排序唯一性：在分页查询中，最终排序条件必须包含唯一标识（如主键），即使业务上不需要。

2. 理解SplitQuery限制：SplitQuery虽能缓解笛卡尔积问题，但增加了查询复杂度，需要更谨慎地处理排序和分页。

3. 性能权衡考量：对于简单关联，SingleQuery可能更可靠；复杂关联和大数据集才考虑SplitQuery。

深度技术解析

这个问题实际上反映了数据库理论中的一个基本原则：在没有明确ORDER BY的情况下，SQL结果集的顺序是不保证的。EF Core的SplitQuery机制会生成多个独立查询：

1. 主查询：SELECT ... FROM Photos ORDER BY ... OFFSET 5 LIMIT 5
2. 关联查询：SELECT ... FROM PhotosTags WHERE PhotoId IN (...)

当主排序不稳定时，两个查询的PhotoId集合可能出现偏差，导致关联数据丢失。添加唯一排序后，所有查询都能稳定地定位相同的实体集合。

通过这个案例，我们可以更深入地理解ORM抽象层与实际SQL执行之间的微妙关系，以及在性能优化时需要特别注意的边界条件。