参数嗅探的问题
原因：（1）可能是发生了参数嗅探，第一次赋给存储过程的输入参数，会为该存储过程生成一个基于输入参数的执行计划，因此如果第一次输入的参数不具有代表性（例如大部分查询输入的参数都是A值，但第一次执行存储过程时输入的是B值），就有可能比即席查询慢，尽管即席查询需要重新编译执行计划，但选择了更有效率的计划。
尝试使用和即席查询一样的参数，来执行存储过程，然后对比一下两者的执行计划。
（2）通常存储过程最上面有自带的set设置，如set ansi_nulls on，而即席查询通常没有包含，这些set设置也会影响执行计划。
尝试在即席查询中添加上，与存储过程一样的set设置，然后再对比一下执行计划。
解决方案：
1)通过使用declare声明的变量来代替参数：使用set @variable=@thedate的方式，将出现@thedate的sql语句全部用@variable来代替。
(2) 将受影响的sql语句隐藏起来，比如：
a) 将受影响的sql语句放到某个子存储过程中，比如我们在@thedate设置成为今天后再调用一个字存储过程将@thedate作为参数传入就可以了。
b) 使用sp_executesql来执行受影响的sql。执行计划不会被执行，除非sp_executesql语句执行完。
c) 使用动态sql（”EXEC(@sql)”来执行受影响的sql。
![[转]Mysql中的SQL优化与执行计划](https://www.kunjuke.com/file/css/thumb/10.jpg/280-180.jpg)