EF Core 高级试题 01：查询翻译与客户端计算
001 关于LINQ 查询翻译，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. EF Core 查询提供程序把可识别的 LINQ 表达式翻译为数据库查询，而不是执行任意 C# 代码
- B. 只要代码能编译为 Expression 就一定能翻译成 SQL
- C. 可翻译能力取决于提供程序和版本，相同表达式在不同数据库上可能不同
- D. 只要观察到“更换数据库提供程序后查询失败”，就能把这次现象视为所有环境中的固定行为。
查看答案与解析
正确答案A
正确项给出了LINQ 查询翻译可直接依赖的规则：“EF Core 查询提供程序把可识别的 LINQ 表达式翻译为数据库查询，而不是执行任意 C# 代码”。“可翻译能力取决于提供程序和版本，相同表达式在不同数据库上可能不同”是应用规则前必须确认的边界，不是规则本身；“只要代码能编译为 Expression 就一定能翻译成 SQL”则把常见现象或实现细节扩大成了平台保证。场景“更换数据库提供程序后查询失败”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
002 生产环境出现“更换数据库提供程序后查询失败”时，针对LINQ 查询翻译应如何排查？
难度： 进阶
- A. 直接采用“只要代码能编译为 Expression 就一定能翻译成 SQL”解释现象，不再收集目标进程和发布配置证据。
- B. 先验证“可翻译能力取决于提供程序和版本，相同表达式在不同数据库上可能不同”，再使用运行时指标、日志或最小复现检查“EF Core 查询提供程序把可识别的 LINQ 表达式翻译为数据库查询，而不是执行任意 C# 代码”是否成立。
- C. 只增加机器资源或重启进程，以一次恢复结果代替对“可翻译能力取决于提供程序和版本，相同表达式在不同数据库上可能不同”的验证。
- D. 只检查代码是否能够编译，通过后便认定“EF Core 查询提供程序把可识别的 LINQ 表达式翻译为数据库查询，而不是执行任意 C# 代码”在当前部署中必然成立。
查看答案与解析
正确答案B
“更换数据库提供程序后查询失败”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“可翻译能力取决于提供程序和版本，相同表达式在不同数据库上可能不同”，再以“EF Core 查询提供程序把可识别的 LINQ 表达式翻译为数据库查询，而不是执行任意 C# 代码”组织证据。采用误区“只要代码能编译为 Expression 就一定能翻译成 SQL”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
003 评审LINQ 查询翻译相关实现时，以下哪项判断不成立？
难度： 实战
- A. EF Core 查询提供程序把可识别的 LINQ 表达式翻译为数据库查询，而不是执行任意 C# 代码
- B. 可翻译能力取决于提供程序和版本，相同表达式在不同数据库上可能不同
- C. 遇到“更换数据库提供程序后查询失败”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
- D. 只要代码能编译为 Expression 就一定能翻译成 SQL
查看答案与解析
正确答案D
题目要求找出不成立的判断，“只要代码能编译为 Expression 就一定能翻译成 SQL”正是LINQ 查询翻译的典型误区。主规则“EF Core 查询提供程序把可识别的 LINQ 表达式翻译为数据库查询，而不是执行任意 C# 代码”描述了实现应依赖的契约，边界“可翻译能力取决于提供程序和版本，相同表达式在不同数据库上可能不同”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
004 准备上线涉及LINQ 查询翻译的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“只要代码能编译为 Expression 就一定能翻译成 SQL”完成修改，只要本地运行一次成功就立即发布。
- B. 按照“EF Core 查询提供程序把可识别的 LINQ 表达式翻译为数据库查询，而不是执行任意 C# 代码”修改代码，但不核对“可翻译能力取决于提供程序和版本，相同表达式在不同数据库上可能不同”或目标发布模式。
- C. 依据“EF Core 查询提供程序把可识别的 LINQ 表达式翻译为数据库查询，而不是执行任意 C# 代码”实现，在“可翻译能力取决于提供程序和版本，相同表达式在不同数据库上可能不同”成立的环境中验证，并为“更换数据库提供程序后查询失败”保留可观测证据和回退条件。
- D. 只验证“可翻译能力取决于提供程序和版本，相同表达式在不同数据库上可能不同”，实现仍继续依赖“只要代码能编译为 Expression 就一定能翻译成 SQL”这一未经证明的假设。
查看答案与解析
正确答案C
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“EF Core 查询提供程序把可识别的 LINQ 表达式翻译为数据库查询，而不是执行任意 C# 代码”，部署环境满足“可翻译能力取决于提供程序和版本，相同表达式在不同数据库上可能不同”，并能在“更换数据库提供程序后查询失败”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
005 关于顶层投影客户端计算，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. 所有无法翻译的表达式都会自动下载整张表再计算
- B. EF Core 可在顶层投影中对无法翻译的部分进行客户端计算，其余查询仍在服务器执行
- C. 过滤、排序等关键位置不可翻译通常会抛异常而不是静默拉取全表
- D. 只要观察到“Select 中调用本地格式化方法”，就能把这次现象视为所有环境中的固定行为。
查看答案与解析
正确答案B
正确项给出了顶层投影客户端计算可直接依赖的规则：“EF Core 可在顶层投影中对无法翻译的部分进行客户端计算，其余查询仍在服务器执行”。“过滤、排序等关键位置不可翻译通常会抛异常而不是静默拉取全表”是应用规则前必须确认的边界，不是规则本身；“所有无法翻译的表达式都会自动下载整张表再计算”则把常见现象或实现细节扩大成了平台保证。场景“Select 中调用本地格式化方法”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
006 生产环境出现“Select 中调用本地格式化方法”时，针对顶层投影客户端计算应如何排查？
难度： 进阶
- A. 直接采用“所有无法翻译的表达式都会自动下载整张表再计算”解释现象，不再收集目标进程和发布配置证据。
- B. 只增加机器资源或重启进程，以一次恢复结果代替对“过滤、排序等关键位置不可翻译通常会抛异常而不是静默拉取全表”的验证。
- C. 先验证“过滤、排序等关键位置不可翻译通常会抛异常而不是静默拉取全表”，再使用运行时指标、日志或最小复现检查“EF Core 可在顶层投影中对无法翻译的部分进行客户端计算，其余查询仍在服务器执行”是否成立。
- D. 只检查代码是否能够编译，通过后便认定“EF Core 可在顶层投影中对无法翻译的部分进行客户端计算，其余查询仍在服务器执行”在当前部署中必然成立。
查看答案与解析
正确答案C
“Select 中调用本地格式化方法”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“过滤、排序等关键位置不可翻译通常会抛异常而不是静默拉取全表”，再以“EF Core 可在顶层投影中对无法翻译的部分进行客户端计算，其余查询仍在服务器执行”组织证据。采用误区“所有无法翻译的表达式都会自动下载整张表再计算”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
007 评审顶层投影客户端计算相关实现时，以下哪项判断不成立？
难度： 实战
- A. 所有无法翻译的表达式都会自动下载整张表再计算
- B. EF Core 可在顶层投影中对无法翻译的部分进行客户端计算，其余查询仍在服务器执行
- C. 过滤、排序等关键位置不可翻译通常会抛异常而不是静默拉取全表
- D. 遇到“Select 中调用本地格式化方法”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
查看答案与解析
正确答案A
题目要求找出不成立的判断，“所有无法翻译的表达式都会自动下载整张表再计算”正是顶层投影客户端计算的典型误区。主规则“EF Core 可在顶层投影中对无法翻译的部分进行客户端计算，其余查询仍在服务器执行”描述了实现应依赖的契约，边界“过滤、排序等关键位置不可翻译通常会抛异常而不是静默拉取全表”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
008 准备上线涉及顶层投影客户端计算的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“所有无法翻译的表达式都会自动下载整张表再计算”完成修改，只要本地运行一次成功就立即发布。
- B. 按照“EF Core 可在顶层投影中对无法翻译的部分进行客户端计算，其余查询仍在服务器执行”修改代码，但不核对“过滤、排序等关键位置不可翻译通常会抛异常而不是静默拉取全表”或目标发布模式。
- C. 只验证“过滤、排序等关键位置不可翻译通常会抛异常而不是静默拉取全表”，实现仍继续依赖“所有无法翻译的表达式都会自动下载整张表再计算”这一未经证明的假设。
- D. 依据“EF Core 可在顶层投影中对无法翻译的部分进行客户端计算，其余查询仍在服务器执行”实现，在“过滤、排序等关键位置不可翻译通常会抛异常而不是静默拉取全表”成立的环境中验证，并为“Select 中调用本地格式化方法”保留可观测证据和回退条件。
查看答案与解析
正确答案D
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“EF Core 可在顶层投影中对无法翻译的部分进行客户端计算，其余查询仍在服务器执行”，部署环境满足“过滤、排序等关键位置不可翻译通常会抛异常而不是静默拉取全表”，并能在“Select 中调用本地格式化方法”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
009 关于参数化，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. 使用 LINQ 后所有动态查询结构都会自动参数化
- B. 动态列名和查询结构不能简单当作普通值参数化
- C. 可参数化值通常作为数据库参数发送，有助于复用查询计划并避免把数据拼接进命令文本
- D. 只要观察到“动态筛选导致大量不同查询形状”，就能把这次现象视为所有环境中的固定行为。
查看答案与解析
正确答案C
正确项给出了参数化可直接依赖的规则：“可参数化值通常作为数据库参数发送，有助于复用查询计划并避免把数据拼接进命令文本”。“动态列名和查询结构不能简单当作普通值参数化”是应用规则前必须确认的边界，不是规则本身；“使用 LINQ 后所有动态查询结构都会自动参数化”则把常见现象或实现细节扩大成了平台保证。场景“动态筛选导致大量不同查询形状”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
010 生产环境出现“动态筛选导致大量不同查询形状”时，针对参数化应如何排查？
难度： 进阶
- A. 直接采用“使用 LINQ 后所有动态查询结构都会自动参数化”解释现象，不再收集目标进程和发布配置证据。
- B. 先验证“动态列名和查询结构不能简单当作普通值参数化”，再使用运行时指标、日志或最小复现检查“可参数化值通常作为数据库参数发送，有助于复用查询计划并避免把数据拼接进命令文本”是否成立。
- C. 只增加机器资源或重启进程，以一次恢复结果代替对“动态列名和查询结构不能简单当作普通值参数化”的验证。
- D. 只检查代码是否能够编译，通过后便认定“可参数化值通常作为数据库参数发送，有助于复用查询计划并避免把数据拼接进命令文本”在当前部署中必然成立。
查看答案与解析
正确答案B
“动态筛选导致大量不同查询形状”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“动态列名和查询结构不能简单当作普通值参数化”，再以“可参数化值通常作为数据库参数发送，有助于复用查询计划并避免把数据拼接进命令文本”组织证据。采用误区“使用 LINQ 后所有动态查询结构都会自动参数化”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
011 评审参数化相关实现时，以下哪项判断不成立？
难度： 实战
- A. 可参数化值通常作为数据库参数发送，有助于复用查询计划并避免把数据拼接进命令文本
- B. 动态列名和查询结构不能简单当作普通值参数化
- C. 遇到“动态筛选导致大量不同查询形状”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
- D. 使用 LINQ 后所有动态查询结构都会自动参数化
查看答案与解析
正确答案D
题目要求找出不成立的判断，“使用 LINQ 后所有动态查询结构都会自动参数化”正是参数化的典型误区。主规则“可参数化值通常作为数据库参数发送，有助于复用查询计划并避免把数据拼接进命令文本”描述了实现应依赖的契约，边界“动态列名和查询结构不能简单当作普通值参数化”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
012 准备上线涉及参数化的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“可参数化值通常作为数据库参数发送，有助于复用查询计划并避免把数据拼接进命令文本”实现，在“动态列名和查询结构不能简单当作普通值参数化”成立的环境中验证，并为“动态筛选导致大量不同查询形状”保留可观测证据和回退条件。
- B. 依据“使用 LINQ 后所有动态查询结构都会自动参数化”完成修改，只要本地运行一次成功就立即发布。
- C. 按照“可参数化值通常作为数据库参数发送，有助于复用查询计划并避免把数据拼接进命令文本”修改代码，但不核对“动态列名和查询结构不能简单当作普通值参数化”或目标发布模式。
- D. 只验证“动态列名和查询结构不能简单当作普通值参数化”，实现仍继续依赖“使用 LINQ 后所有动态查询结构都会自动参数化”这一未经证明的假设。
查看答案与解析
正确答案A
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“可参数化值通常作为数据库参数发送，有助于复用查询计划并避免把数据拼接进命令文本”，部署环境满足“动态列名和查询结构不能简单当作普通值参数化”，并能在“动态筛选导致大量不同查询形状”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
013 关于查询边界，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. 调用 AsEnumerable 只改变静态类型而不改变后续执行位置
- B. 切换客户端前仍在查询表达式中的操作可继续由数据库执行
- C. 只要观察到“过滤写在 AsEnumerable 后导致传输量激增”，就能把这次现象视为所有环境中的固定行为。
- D. AsEnumerable 或物化操作会把后续运算移到客户端，应明确评估数据量和执行位置
查看答案与解析
正确答案D
正确项给出了查询边界可直接依赖的规则：“AsEnumerable 或物化操作会把后续运算移到客户端，应明确评估数据量和执行位置”。“切换客户端前仍在查询表达式中的操作可继续由数据库执行”是应用规则前必须确认的边界，不是规则本身；“调用 AsEnumerable 只改变静态类型而不改变后续执行位置”则把常见现象或实现细节扩大成了平台保证。场景“过滤写在 AsEnumerable 后导致传输量激增”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
014 生产环境出现“过滤写在 AsEnumerable 后导致传输量激增”时，针对查询边界应如何排查？
难度： 进阶
- A. 直接采用“调用 AsEnumerable 只改变静态类型而不改变后续执行位置”解释现象，不再收集目标进程和发布配置证据。
- B. 只增加机器资源或重启进程，以一次恢复结果代替对“切换客户端前仍在查询表达式中的操作可继续由数据库执行”的验证。
- C. 先验证“切换客户端前仍在查询表达式中的操作可继续由数据库执行”，再使用运行时指标、日志或最小复现检查“AsEnumerable 或物化操作会把后续运算移到客户端，应明确评估数据量和执行位置”是否成立。
- D. 只检查代码是否能够编译，通过后便认定“AsEnumerable 或物化操作会把后续运算移到客户端，应明确评估数据量和执行位置”在当前部署中必然成立。
查看答案与解析
正确答案C
“过滤写在 AsEnumerable 后导致传输量激增”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“切换客户端前仍在查询表达式中的操作可继续由数据库执行”，再以“AsEnumerable 或物化操作会把后续运算移到客户端，应明确评估数据量和执行位置”组织证据。采用误区“调用 AsEnumerable 只改变静态类型而不改变后续执行位置”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
015 评审查询边界相关实现时，以下哪项判断不成立？
难度： 实战
- A. 调用 AsEnumerable 只改变静态类型而不改变后续执行位置
- B. AsEnumerable 或物化操作会把后续运算移到客户端，应明确评估数据量和执行位置
- C. 切换客户端前仍在查询表达式中的操作可继续由数据库执行
- D. 遇到“过滤写在 AsEnumerable 后导致传输量激增”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
查看答案与解析
正确答案A
题目要求找出不成立的判断，“调用 AsEnumerable 只改变静态类型而不改变后续执行位置”正是查询边界的典型误区。主规则“AsEnumerable 或物化操作会把后续运算移到客户端，应明确评估数据量和执行位置”描述了实现应依赖的契约，边界“切换客户端前仍在查询表达式中的操作可继续由数据库执行”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
016 准备上线涉及查询边界的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“调用 AsEnumerable 只改变静态类型而不改变后续执行位置”完成修改，只要本地运行一次成功就立即发布。
- B. 依据“AsEnumerable 或物化操作会把后续运算移到客户端，应明确评估数据量和执行位置”实现，在“切换客户端前仍在查询表达式中的操作可继续由数据库执行”成立的环境中验证，并为“过滤写在 AsEnumerable 后导致传输量激增”保留可观测证据和回退条件。
- C. 按照“AsEnumerable 或物化操作会把后续运算移到客户端，应明确评估数据量和执行位置”修改代码，但不核对“切换客户端前仍在查询表达式中的操作可继续由数据库执行”或目标发布模式。
- D. 只验证“切换客户端前仍在查询表达式中的操作可继续由数据库执行”，实现仍继续依赖“调用 AsEnumerable 只改变静态类型而不改变后续执行位置”这一未经证明的假设。
查看答案与解析
正确答案B
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“AsEnumerable 或物化操作会把后续运算移到客户端，应明确评估数据量和执行位置”，部署环境满足“切换客户端前仍在查询表达式中的操作可继续由数据库执行”，并能在“过滤写在 AsEnumerable 后导致传输量激增”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
017 关于查询日志，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. 查看生成命令、参数和数据库执行计划比仅阅读 LINQ 更能确认真实执行行为
- B. LINQ 代码简短就能证明查询一定高效
- C. 敏感数据日志只能在受控环境启用，生产诊断应避免泄露参数
- D. 只要观察到“接口变慢但代码审查看不出原因”，就能把这次现象视为所有环境中的固定行为。
查看答案与解析
正确答案A
正确项给出了查询日志可直接依赖的规则：“查看生成命令、参数和数据库执行计划比仅阅读 LINQ 更能确认真实执行行为”。“敏感数据日志只能在受控环境启用，生产诊断应避免泄露参数”是应用规则前必须确认的边界，不是规则本身；“LINQ 代码简短就能证明查询一定高效”则把常见现象或实现细节扩大成了平台保证。场景“接口变慢但代码审查看不出原因”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
018 生产环境出现“接口变慢但代码审查看不出原因”时，针对查询日志应如何排查？
难度： 进阶
- A. 直接采用“LINQ 代码简短就能证明查询一定高效”解释现象，不再收集目标进程和发布配置证据。
- B. 只增加机器资源或重启进程，以一次恢复结果代替对“敏感数据日志只能在受控环境启用，生产诊断应避免泄露参数”的验证。
- C. 只检查代码是否能够编译，通过后便认定“查看生成命令、参数和数据库执行计划比仅阅读 LINQ 更能确认真实执行行为”在当前部署中必然成立。
- D. 先验证“敏感数据日志只能在受控环境启用，生产诊断应避免泄露参数”，再使用运行时指标、日志或最小复现检查“查看生成命令、参数和数据库执行计划比仅阅读 LINQ 更能确认真实执行行为”是否成立。
查看答案与解析
正确答案D
“接口变慢但代码审查看不出原因”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“敏感数据日志只能在受控环境启用，生产诊断应避免泄露参数”，再以“查看生成命令、参数和数据库执行计划比仅阅读 LINQ 更能确认真实执行行为”组织证据。采用误区“LINQ 代码简短就能证明查询一定高效”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
019 评审查询日志相关实现时，以下哪项判断不成立？
难度： 实战
- A. 查看生成命令、参数和数据库执行计划比仅阅读 LINQ 更能确认真实执行行为
- B. 敏感数据日志只能在受控环境启用，生产诊断应避免泄露参数
- C. LINQ 代码简短就能证明查询一定高效
- D. 遇到“接口变慢但代码审查看不出原因”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
查看答案与解析
正确答案C
题目要求找出不成立的判断，“LINQ 代码简短就能证明查询一定高效”正是查询日志的典型误区。主规则“查看生成命令、参数和数据库执行计划比仅阅读 LINQ 更能确认真实执行行为”描述了实现应依赖的契约，边界“敏感数据日志只能在受控环境启用，生产诊断应避免泄露参数”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
020 准备上线涉及查询日志的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“LINQ 代码简短就能证明查询一定高效”完成修改，只要本地运行一次成功就立即发布。
- B. 依据“查看生成命令、参数和数据库执行计划比仅阅读 LINQ 更能确认真实执行行为”实现，在“敏感数据日志只能在受控环境启用，生产诊断应避免泄露参数”成立的环境中验证，并为“接口变慢但代码审查看不出原因”保留可观测证据和回退条件。
- C. 按照“查看生成命令、参数和数据库执行计划比仅阅读 LINQ 更能确认真实执行行为”修改代码，但不核对“敏感数据日志只能在受控环境启用，生产诊断应避免泄露参数”或目标发布模式。
- D. 只验证“敏感数据日志只能在受控环境启用，生产诊断应避免泄露参数”，实现仍继续依赖“LINQ 代码简短就能证明查询一定高效”这一未经证明的假设。
查看答案与解析
正确答案B
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“查看生成命令、参数和数据库执行计划比仅阅读 LINQ 更能确认真实执行行为”，部署环境满足“敏感数据日志只能在受控环境启用，生产诊断应避免泄露参数”，并能在“接口变慢但代码审查看不出原因”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。