EF Core 的 Single Query 是默认的单条 JOIN 查询，用于避免 N+1 问题；正确使用 Include/ThenInclude 可触发它，但子集过滤或错误链式调用会退化为 Split Query 或报错。
EF Core 的 Single Query（单查询）并不是一个显式调用的方法，而是指 EF Core 在使用 Include 进行预加载（Eager Loading）时，默认生成的 **一条 SQL JOIN 查询** —— 也就是把主表和关联表的数据一次性查出来，避免 N+1 查询问题。它本质是 EF Core 的默认行为，但需要正确使用才能真正生效。
什么时候会生成 Single Query？
当你用 Include + ThenInclude 加载关联数据，并且所有导航路径都支持 JOIN（比如一对一、一对多），EF Core 通常会翻译成一条带 LEFT JOIN 或 INNER JOIN 的 SQL 语句。
- 一对多关系（如 Blog → Posts）→ 生成 LEFT JOIN
- 多对一/一对一（如 Post → Author）→ 默认 INNER JOIN，除非配置为可空
- 多个同级
Include（如.Include(x => x.Author).Include(x => x.Tags)）→ 仍是一条 SQL，但可能产生笛卡尔积（需留意）
怎么确保真正用上 Single Query？
关键不是“怎么开启”，而是“怎么不破坏”它：
- 别在
Include后接Where或OrderBy在子集合上（例如.Include(b => b.Posts).Where(b => b.Posts.Any(...))），这会让 EF Core 切换到 Split Query 模式（多条 SQL）或报错 - 避免在
Include链中混用过滤条件（如.Include(b => b.Posts.Where(p => p.IsPublished))），EF Core 6+ 支持这种写法，但底层仍是 Single Query；EF Core 5 及更早版本不支持，会出错 - 如果发现生成了多条 SQL，可以用
context.Database.Log或 SQL Server Profiler 查看实际执行语句
合并多个实体查询的替代方案：Split Queries
当 Single Query 因笛卡尔积导致性能下降（比如一对多再加一对多），EF Core 提供了 AsSplitQuery() 显式启用拆分查询：
- 它会把一个含多个
Include的查询，拆成多条独立 SQL（每条查一个表） - 适合大数据量、深度关联但又不想膨胀结果集的场景
- 用法：
context.Blogs.Include(b => b.Posts).ThenInclude(p => p.Author).AsSplitQuery().ToList()
不推荐但有时可行的“手动合并”方式
如果你真想把几个不同实体的查询“合并在一次数据库往返中”，EF Core 本身不支持跨 DbContext 或跨 DbSet 的 UNION 类型合并。可行思路有：
- 用原始 SQL（
context.Blogs.FromSqlRaw("SELECT ... UNION SELECT ...")），但要自己映射结果 - 用
JoinLINQ 写法代替Include，只取需要字段（更轻量，无实体图） - 业务层合并：分别查
Blogs、Posts、Authors，再用 C# 关联（适合缓存友好或复杂筛选场景）
基本上就这些。Single Query 是默认且高效的起点，重点是别无意中把它“切开”——理解 Include 的边界，比记住语法更重要。
