我有一个名为resetflags的存储过程（sproc）。它需要一个int参数。另一个存储过程editInspection调用它
- 更新表上的单行（持续时间<0.00秒）
- 执行另一个存储过程（持续时间<0.00秒）
- 执行存储过程重置标记（持续时间约16秒！！）
- 选择单行（持续时间<0.00秒）
如果我注释掉第3行并运行存储过程，它将在0秒内完成。如果我自己跑3号线，它会在1秒内结束。如果我注释掉第1行和第2行，存储过程需要16秒。
数据库中不包含任何触发器（我是一个不太喜欢触发器的人）。任何地方都没有用户分配的事务。我使用的是SQL 2008开发人员版。
我刚刚使用探查器对它和其他一些测试脚本进行了计时。以下是我的发现：
案例1：运行脚本以使用参数执行存储过程editInspection。耗时16000毫秒。
案例2：创建了一个测试脚本。已更改为存储过程editInspection的代码，因此所有参数都是本地变量。将值分配给这些本地变量，然后执行代码。耗时约16000毫秒。
案例3：从存储过程editInspection中注释出"exec resetflags"，然后运行以下内容：
执行editInspection param1，。。。参数n执行resetflags param1
因此，存储过程resetflag现在在存储过程editInspection之外运行。这花了600-700毫秒才完成。
案例4：从案例2中获取测试脚本。注释掉了除一个变量声明和赋值之外的所有变量。列举了除执行resetFlags之外的所有其他语句。所以脚本基本上是
声明param1 int/*注释掉了声明stmts/SET param1=某个值/注释掉SET语句已注释掉SELECT、UPDATE和EXECUTE*/执行resetFlags param1
这一次耗时约16000毫秒。
案例5：复制案例4中的代码，并将其粘贴到一个新的查询窗口中。执行了它，大约花了700毫秒！这是奇怪的部分。
情况6：执行的存储过程reset标记参数的值。耗时约600毫秒。
任何关于寻找什么的线索都将不胜感激。我知道我还没有发布代码/表定义和示例数据。定义和代码都很大，我也很懒。
我强烈建议将参数嗅探作为罪魁祸首。