ASP.NET Core 试题 46：EF Core 查询与数据加载
0901 在 投影 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 匿名类型投影一定不会包含或跟踪任何实体
- B. Select 只读取所需列可减少网络、物化和跟踪成本
- C. 投影包含实体实例时该实体仍可能被跟踪，应检查结果形状和 TrackingBehavior
- D. 观察到“只选部分字段却意外返回完整实体导航”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 投影 的主规则：Select 只读取所需列可减少网络、物化和跟踪成本。选项“投影包含实体实例时该实体仍可能被跟踪，应检查结果形状和 TrackingBehavior”是使用规则时要验证的边界，不是规则本身；“匿名类型投影一定不会包含或跟踪任何实体”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0902 只选部分字段却意外返回完整实体导航。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“匿名类型投影一定不会包含或跟踪任何实体”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“投影包含实体实例时该实体仍可能被跟踪，应检查结果形状和 TrackingBehavior”。
- C. 以一次成功请求作为结论，不再确认“Select 只读取所需列可减少网络、物化和跟踪成本”是否成立。
- D. 先验证“投影包含实体实例时该实体仍可能被跟踪，应检查结果形状和 TrackingBehavior”，再依据“Select 只读取所需列可减少网络、物化和跟踪成本”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“只选部分字段却意外返回完整实体导航”指向 投影，但症状本身不能证明根因。正确排查应先确认边界“投影包含实体实例时该实体仍可能被跟踪，应检查结果形状和 TrackingBehavior”，再用主规则“Select 只读取所需列可减少网络、物化和跟踪成本”解释证据。直接采用误区“匿名类型投影一定不会包含或跟踪任何实体”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0903 关于 投影，以下哪项说法不成立？
难度： 实战
- A. 匿名类型投影一定不会包含或跟踪任何实体
- B. Select 只读取所需列可减少网络、物化和跟踪成本
- C. 投影包含实体实例时该实体仍可能被跟踪，应检查结果形状和 TrackingBehavior
- D. 出现“只选部分字段却意外返回完整实体导航”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“匿名类型投影一定不会包含或跟踪任何实体”正是 投影 的典型误区。其余三项分别给出了主规则“Select 只读取所需列可减少网络、物化和跟踪成本”、适用边界“投影包含实体实例时该实体仍可能被跟踪，应检查结果形状和 TrackingBehavior”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0904 针对“只选部分字段却意外返回完整实体导航”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“匿名类型投影一定不会包含或跟踪任何实体”修改实现，并把一次请求成功作为验收结果。
- B. 按“Select 只读取所需列可减少网络、物化和跟踪成本”修改代码后直接上线，不验证“投影包含实体实例时该实体仍可能被跟踪，应检查结果形状和 TrackingBehavior”。
- C. 按“Select 只读取所需列可减少网络、物化和跟踪成本”修正实现，并用测试或遥测验证“投影包含实体实例时该实体仍可能被跟踪，应检查结果形状和 TrackingBehavior”。
- D. 只验证“投影包含实体实例时该实体仍可能被跟踪，应检查结果形状和 TrackingBehavior”，但实现仍继续依赖“匿名类型投影一定不会包含或跟踪任何实体”。
查看答案与解析
正确答案C
完整决策同时覆盖规则与验证：Select 只读取所需列可减少网络、物化和跟踪成本；并确认 投影包含实体实例时该实体仍可能被跟踪，应检查结果形状和 TrackingBehavior。继续接受“匿名类型投影一定不会包含或跟踪任何实体”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“只选部分字段却意外返回完整实体导航”这一生产场景能否安全上线。
0905 在 N+1 查询 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 开启 Lazy Loading 会自动把所有 N+1 合并成一个 JOIN
- B. 可用投影、Include 或批量查询消除，但要避免一次加载过多无用数据
- C. 循环中逐个懒加载或查询导航会产生一条主查询加大量子查询
- D. 观察到“列表页面随行数增加数据库往返激增”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案C
正确答案直接描述 N+1 查询 的主规则：循环中逐个懒加载或查询导航会产生一条主查询加大量子查询。选项“可用投影、Include 或批量查询消除，但要避免一次加载过多无用数据”是使用规则时要验证的边界，不是规则本身；“开启 Lazy Loading 会自动把所有 N+1 合并成一个 JOIN”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0906 列表页面随行数增加数据库往返激增。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“开启 Lazy Loading 会自动把所有 N+1 合并成一个 JOIN”定性，不再检查配置、身份或运行时证据。
- B. 先验证“可用投影、Include 或批量查询消除，但要避免一次加载过多无用数据”，再依据“循环中逐个懒加载或查询导航会产生一条主查询加大量子查询”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“可用投影、Include 或批量查询消除，但要避免一次加载过多无用数据”。
- D. 以一次成功请求作为结论，不再确认“循环中逐个懒加载或查询导航会产生一条主查询加大量子查询”是否成立。
查看答案与解析
正确答案B
场景“列表页面随行数增加数据库往返激增”指向 N+1 查询，但症状本身不能证明根因。正确排查应先确认边界“可用投影、Include 或批量查询消除，但要避免一次加载过多无用数据”，再用主规则“循环中逐个懒加载或查询导航会产生一条主查询加大量子查询”解释证据。直接采用误区“开启 Lazy Loading 会自动把所有 N+1 合并成一个 JOIN”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0907 关于 N+1 查询，以下哪项说法不成立？
难度： 实战
- A. 循环中逐个懒加载或查询导航会产生一条主查询加大量子查询
- B. 可用投影、Include 或批量查询消除，但要避免一次加载过多无用数据
- C. 出现“列表页面随行数增加数据库往返激增”时，应收集证据并同时核对主规则与适用边界。
- D. 开启 Lazy Loading 会自动把所有 N+1 合并成一个 JOIN
查看答案与解析
正确答案D
题目要求选出不成立的说法，答案“开启 Lazy Loading 会自动把所有 N+1 合并成一个 JOIN”正是 N+1 查询 的典型误区。其余三项分别给出了主规则“循环中逐个懒加载或查询导航会产生一条主查询加大量子查询”、适用边界“可用投影、Include 或批量查询消除，但要避免一次加载过多无用数据”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0908 针对“列表页面随行数增加数据库往返激增”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“循环中逐个懒加载或查询导航会产生一条主查询加大量子查询”修正实现，并用测试或遥测验证“可用投影、Include 或批量查询消除，但要避免一次加载过多无用数据”。
- B. 按“开启 Lazy Loading 会自动把所有 N+1 合并成一个 JOIN”修改实现，并把一次请求成功作为验收结果。
- C. 按“循环中逐个懒加载或查询导航会产生一条主查询加大量子查询”修改代码后直接上线，不验证“可用投影、Include 或批量查询消除，但要避免一次加载过多无用数据”。
- D. 只验证“可用投影、Include 或批量查询消除，但要避免一次加载过多无用数据”，但实现仍继续依赖“开启 Lazy Loading 会自动把所有 N+1 合并成一个 JOIN”。
查看答案与解析
正确答案A
完整决策同时覆盖规则与验证：循环中逐个懒加载或查询导航会产生一条主查询加大量子查询；并确认 可用投影、Include 或批量查询消除，但要避免一次加载过多无用数据。继续接受“开启 Lazy Loading 会自动把所有 N+1 合并成一个 JOIN”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“列表页面随行数增加数据库往返激增”这一生产场景能否安全上线。
0909 在 Include 与笛卡尔膨胀 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 增加 Include 只改变客户端对象图，不改变 SQL 和结果行数
- B. 应根据数据规模选择投影、拆分查询或单独批量加载，并测量往返与数据量
- C. 观察到“两个集合各十项导致返回约百行组合”即可把一次现象当成完整框架契约。
- D. 同级多个集合 Include 的单查询 JOIN 可能造成笛卡尔膨胀和重复大列
查看答案与解析
正确答案D
正确答案直接描述 Include 与笛卡尔膨胀 的主规则：同级多个集合 Include 的单查询 JOIN 可能造成笛卡尔膨胀和重复大列。选项“应根据数据规模选择投影、拆分查询或单独批量加载，并测量往返与数据量”是使用规则时要验证的边界，不是规则本身；“增加 Include 只改变客户端对象图，不改变 SQL 和结果行数”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0910 两个集合各十项导致返回约百行组合。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“增加 Include 只改变客户端对象图，不改变 SQL 和结果行数”定性，不再检查配置、身份或运行时证据。
- B. 先验证“应根据数据规模选择投影、拆分查询或单独批量加载，并测量往返与数据量”，再依据“同级多个集合 Include 的单查询 JOIN 可能造成笛卡尔膨胀和重复大列”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“应根据数据规模选择投影、拆分查询或单独批量加载，并测量往返与数据量”。
- D. 以一次成功请求作为结论，不再确认“同级多个集合 Include 的单查询 JOIN 可能造成笛卡尔膨胀和重复大列”是否成立。
查看答案与解析
正确答案B
场景“两个集合各十项导致返回约百行组合”指向 Include 与笛卡尔膨胀，但症状本身不能证明根因。正确排查应先确认边界“应根据数据规模选择投影、拆分查询或单独批量加载，并测量往返与数据量”，再用主规则“同级多个集合 Include 的单查询 JOIN 可能造成笛卡尔膨胀和重复大列”解释证据。直接采用误区“增加 Include 只改变客户端对象图，不改变 SQL 和结果行数”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0911 关于 Include 与笛卡尔膨胀，以下哪项说法不成立？
难度： 实战
- A. 增加 Include 只改变客户端对象图，不改变 SQL 和结果行数
- B. 同级多个集合 Include 的单查询 JOIN 可能造成笛卡尔膨胀和重复大列
- C. 应根据数据规模选择投影、拆分查询或单独批量加载，并测量往返与数据量
- D. 出现“两个集合各十项导致返回约百行组合”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“增加 Include 只改变客户端对象图，不改变 SQL 和结果行数”正是 Include 与笛卡尔膨胀 的典型误区。其余三项分别给出了主规则“同级多个集合 Include 的单查询 JOIN 可能造成笛卡尔膨胀和重复大列”、适用边界“应根据数据规模选择投影、拆分查询或单独批量加载，并测量往返与数据量”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0912 针对“两个集合各十项导致返回约百行组合”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“增加 Include 只改变客户端对象图，不改变 SQL 和结果行数”修改实现，并把一次请求成功作为验收结果。
- B. 按“同级多个集合 Include 的单查询 JOIN 可能造成笛卡尔膨胀和重复大列”修改代码后直接上线，不验证“应根据数据规模选择投影、拆分查询或单独批量加载，并测量往返与数据量”。
- C. 按“同级多个集合 Include 的单查询 JOIN 可能造成笛卡尔膨胀和重复大列”修正实现，并用测试或遥测验证“应根据数据规模选择投影、拆分查询或单独批量加载，并测量往返与数据量”。
- D. 只验证“应根据数据规模选择投影、拆分查询或单独批量加载，并测量往返与数据量”，但实现仍继续依赖“增加 Include 只改变客户端对象图，不改变 SQL 和结果行数”。
查看答案与解析
正确答案C
完整决策同时覆盖规则与验证：同级多个集合 Include 的单查询 JOIN 可能造成笛卡尔膨胀和重复大列；并确认 应根据数据规模选择投影、拆分查询或单独批量加载，并测量往返与数据量。继续接受“增加 Include 只改变客户端对象图，不改变 SQL 和结果行数”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“两个集合各十项导致返回约百行组合”这一生产场景能否安全上线。
0913 在 Split Query 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. AsSplitQuery 为包含集合的查询生成多条 SQL，避免单查询笛卡尔膨胀
- B. Split Query 总是在一个数据库快照中原子执行且只有一次往返
- C. 会增加往返且多查询间可能看到不一致数据，分页时还需保证完全唯一排序
- D. 观察到“并发修改时主表与子表结果不一致”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 Split Query 的主规则：AsSplitQuery 为包含集合的查询生成多条 SQL，避免单查询笛卡尔膨胀。选项“会增加往返且多查询间可能看到不一致数据，分页时还需保证完全唯一排序”是使用规则时要验证的边界，不是规则本身；“Split Query 总是在一个数据库快照中原子执行且只有一次往返”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0914 并发修改时主表与子表结果不一致。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“Split Query 总是在一个数据库快照中原子执行且只有一次往返”定性，不再检查配置、身份或运行时证据。
- B. 先验证“会增加往返且多查询间可能看到不一致数据，分页时还需保证完全唯一排序”，再依据“AsSplitQuery 为包含集合的查询生成多条 SQL，避免单查询笛卡尔膨胀”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“会增加往返且多查询间可能看到不一致数据，分页时还需保证完全唯一排序”。
- D. 以一次成功请求作为结论，不再确认“AsSplitQuery 为包含集合的查询生成多条 SQL，避免单查询笛卡尔膨胀”是否成立。
查看答案与解析
正确答案B
场景“并发修改时主表与子表结果不一致”指向 Split Query，但症状本身不能证明根因。正确排查应先确认边界“会增加往返且多查询间可能看到不一致数据，分页时还需保证完全唯一排序”，再用主规则“AsSplitQuery 为包含集合的查询生成多条 SQL，避免单查询笛卡尔膨胀”解释证据。直接采用误区“Split Query 总是在一个数据库快照中原子执行且只有一次往返”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0915 关于 Split Query，以下哪项说法不成立？
难度： 实战
- A. AsSplitQuery 为包含集合的查询生成多条 SQL，避免单查询笛卡尔膨胀
- B. 会增加往返且多查询间可能看到不一致数据，分页时还需保证完全唯一排序
- C. 出现“并发修改时主表与子表结果不一致”时，应收集证据并同时核对主规则与适用边界。
- D. Split Query 总是在一个数据库快照中原子执行且只有一次往返
查看答案与解析
正确答案D
题目要求选出不成立的说法，答案“Split Query 总是在一个数据库快照中原子执行且只有一次往返”正是 Split Query 的典型误区。其余三项分别给出了主规则“AsSplitQuery 为包含集合的查询生成多条 SQL，避免单查询笛卡尔膨胀”、适用边界“会增加往返且多查询间可能看到不一致数据，分页时还需保证完全唯一排序”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0916 针对“并发修改时主表与子表结果不一致”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“Split Query 总是在一个数据库快照中原子执行且只有一次往返”修改实现，并把一次请求成功作为验收结果。
- B. 按“AsSplitQuery 为包含集合的查询生成多条 SQL，避免单查询笛卡尔膨胀”修改代码后直接上线，不验证“会增加往返且多查询间可能看到不一致数据，分页时还需保证完全唯一排序”。
- C. 按“AsSplitQuery 为包含集合的查询生成多条 SQL，避免单查询笛卡尔膨胀”修正实现，并用测试或遥测验证“会增加往返且多查询间可能看到不一致数据，分页时还需保证完全唯一排序”。
- D. 只验证“会增加往返且多查询间可能看到不一致数据，分页时还需保证完全唯一排序”，但实现仍继续依赖“Split Query 总是在一个数据库快照中原子执行且只有一次往返”。
查看答案与解析
正确答案C
完整决策同时覆盖规则与验证：AsSplitQuery 为包含集合的查询生成多条 SQL，避免单查询笛卡尔膨胀；并确认 会增加往返且多查询间可能看到不一致数据，分页时还需保证完全唯一排序。继续接受“Split Query 总是在一个数据库快照中原子执行且只有一次往返”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“并发修改时主表与子表结果不一致”这一生产场景能否安全上线。
0917 在 客户端求值 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 任何 C# 方法都能自动翻译为所有数据库函数
- B. EF Core 通常只允许顶层投影的部分客户端求值，无法翻译的过滤等会抛异常
- C. 应查看生成 SQL，把可翻译过滤放数据库端，避免先 ToList 再筛选大表
- D. 观察到“自定义方法放 Where 后运行时报无法翻译”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 客户端求值 的主规则：EF Core 通常只允许顶层投影的部分客户端求值，无法翻译的过滤等会抛异常。选项“应查看生成 SQL，把可翻译过滤放数据库端，避免先 ToList 再筛选大表”是使用规则时要验证的边界，不是规则本身；“任何 C# 方法都能自动翻译为所有数据库函数”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0918 自定义方法放 Where 后运行时报无法翻译。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“应查看生成 SQL，把可翻译过滤放数据库端，避免先 ToList 再筛选大表”，再依据“EF Core 通常只允许顶层投影的部分客户端求值，无法翻译的过滤等会抛异常”判断实现是否符合契约。
- B. 直接按“任何 C# 方法都能自动翻译为所有数据库函数”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“应查看生成 SQL，把可翻译过滤放数据库端，避免先 ToList 再筛选大表”。
- D. 以一次成功请求作为结论，不再确认“EF Core 通常只允许顶层投影的部分客户端求值，无法翻译的过滤等会抛异常”是否成立。
查看答案与解析
正确答案A
场景“自定义方法放 Where 后运行时报无法翻译”指向 客户端求值，但症状本身不能证明根因。正确排查应先确认边界“应查看生成 SQL，把可翻译过滤放数据库端，避免先 ToList 再筛选大表”，再用主规则“EF Core 通常只允许顶层投影的部分客户端求值，无法翻译的过滤等会抛异常”解释证据。直接采用误区“任何 C# 方法都能自动翻译为所有数据库函数”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0919 关于 客户端求值，以下哪项说法不成立？
难度： 实战
- A. EF Core 通常只允许顶层投影的部分客户端求值，无法翻译的过滤等会抛异常
- B. 应查看生成 SQL，把可翻译过滤放数据库端，避免先 ToList 再筛选大表
- C. 任何 C# 方法都能自动翻译为所有数据库函数
- D. 出现“自定义方法放 Where 后运行时报无法翻译”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“任何 C# 方法都能自动翻译为所有数据库函数”正是 客户端求值 的典型误区。其余三项分别给出了主规则“EF Core 通常只允许顶层投影的部分客户端求值，无法翻译的过滤等会抛异常”、适用边界“应查看生成 SQL，把可翻译过滤放数据库端，避免先 ToList 再筛选大表”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0920 针对“自定义方法放 Where 后运行时报无法翻译”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“任何 C# 方法都能自动翻译为所有数据库函数”修改实现，并把一次请求成功作为验收结果。
- B. 按“EF Core 通常只允许顶层投影的部分客户端求值，无法翻译的过滤等会抛异常”修改代码后直接上线，不验证“应查看生成 SQL，把可翻译过滤放数据库端，避免先 ToList 再筛选大表”。
- C. 只验证“应查看生成 SQL，把可翻译过滤放数据库端，避免先 ToList 再筛选大表”，但实现仍继续依赖“任何 C# 方法都能自动翻译为所有数据库函数”。
- D. 按“EF Core 通常只允许顶层投影的部分客户端求值，无法翻译的过滤等会抛异常”修正实现，并用测试或遥测验证“应查看生成 SQL，把可翻译过滤放数据库端，避免先 ToList 再筛选大表”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：EF Core 通常只允许顶层投影的部分客户端求值，无法翻译的过滤等会抛异常；并确认 应查看生成 SQL，把可翻译过滤放数据库端，避免先 ToList 再筛选大表。继续接受“任何 C# 方法都能自动翻译为所有数据库函数”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“自定义方法放 Where 后运行时报无法翻译”这一生产场景能否安全上线。