SQL Server参数化高成本SQL使用实际参数测试时成本偏低问题

两个SQL逻辑完全一致，唯一区别是筛选条件一个用常量值、一个用EF生成的参数，这是成本差异的核心来源：

• 常量查询场景下，数据库优化器可以直接获取124396这个具体的筛选值，通过列的统计信息精准预估匹配行数，会直接选择DivisionPoolId列的索引执行查找操作，筛选效率极高，因此整体开销很低。
• 参数化查询场景下，首先EF为了兼容参数为null的查询场景，自动生成了OR (([Extent2].[DivisionPoolId] IS NULL) AND (@p__linq__0 IS NULL))的冗余判断，这个OR条件会导致优化器无法通过参数值做精准的行数预估，只能基于统计信息的平均密度算出远高于实际的预估行数，最终选择了全表扫描/索引扫描的低效执行计划。同时如果存在参数为null的查询提前生成了缓存执行计划，后续非null参数复用该计划也会出现参数嗅探问题，进一步放大性能开销。

• 如果你能确定业务场景中DivisionPoolId参数永远不会为null，可以直接开启EF的数据库空语义配置：DbContext.Configuration.UseDatabaseNullSemantics = true;，开启后EF不会再生成多余的null判断逻辑，谓词简化后优化器就能正常选择索引查找的执行计划。
• 如果需要兼容参数为null的场景，可以在EF查询中添加重编译提示，SQL Server场景下可以加WithOptions(RECOMPILE)，每次查询会基于当前传入的参数值重新生成最优执行计划，避免复用不合适的缓存计划。
• 也可以直接为[Test].[DivisionBracketParticipantPool]表的DivisionPoolId列建立包含Id的覆盖索引，不管是常量还是参数化查询都可以直接通过索引拿到所需数据，避免回表开销。

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