存储过程中SELECT语句顺序为何影响Dapper调用性能？

这种现象的核心原因是**SQL Server的参数嗅探（Parameter Sniffing）**和执行计划缓存机制，和Dapper本身的读取逻辑无关，具体拆解如下：

• 参数嗅探与执行计划缓存：存储过程首次执行时，SQL Server会根据传入的参数值生成最优执行计划并缓存。如果后续调用的参数对应的数据集分布和首次差异极大，缓存的执行计划就会变得低效——比如原本针对小数据集生成的嵌套循环计划，在处理大数据集时会超时。
• 语句顺序影响计划生成：当那条慢查询orderDesignProcessSteps放在存储过程靠后位置时，存储过程的执行计划会优先根据前面语句的参数生成整体计划，这条语句可能被迫复用了不匹配的计划；而将它移到前面后，SQL Server会先针对它的参数生成适配的执行计划，后续语句的计划也会基于更合理的上下文生成，整体效率大幅提升。
• SSMS与C#调用的差异：SSMS和ADO.NET（Dapper基于ADO.NET）的默认会话设置（如ANSI_NULLS、QUOTED_IDENTIFIER等）可能不同，这会导致SQL Server为相同的存储过程生成不同的执行计划。SSMS里执行快，是因为它的会话设置下生成的计划更适配数据，而C#调用时用了另一个低效的缓存计划；调整语句顺序后，新生成的计划在C#的会话设置下也能高效执行。

总结：调整SELECT语句顺序本质上是让SQL Server重新生成了适配当前调用参数的执行计划，绕过了之前低效的缓存计划，和Dapper的多结果集读取逻辑没有直接关系。

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