不久前，我有一个查询，我为我的一个用户运行了很多次。它仍在不断发展和调整，但最终它稳定下来并且运行得相当快，因此我们从中创建了一个存储过程。
到目前为止，一切都很正常。
然而，存储过程却非常慢。查询和过程之间没有实质性差异，但速度变化很大。
[背景，我们正在运行 SQL Server 2005。]
一位友好的当地 DBA（他不再在这里工作）看了一眼存储过程，并说“参数欺骗！” (Edit:尽管它似乎也可能被称为“参数嗅探”，这可能解释了当我试图搜索它时谷歌点击量很少的原因。）
我们将一些存储过程抽象为第二个存储过程，将对这个新内部过程的调用包装到预先存在的外部过程中，称为外部过程，嘿，很快，它和原始查询一样快。
那么，什么给出呢？有人可以解释一下参数欺骗吗？
奖金积分
- 强调如何避免它
- 建议如何识别可能的原因
- 讨论替代策略，例如统计数据、索引、键，用于缓解这种情况
仅供参考 - 当您使用 SQL 2005 和带参数的存储过程时，您需要注意其他事项。
SQL Server 将使用使用的第一个参数编译存储过程的执行计划。所以如果你运行这个：
usp_QueryMyDataByState 'Rhode Island'
执行计划最适合小州的数据。但如果有人转身就跑：
usp_QueryMyDataByState 'Texas'
为罗德岛州大小的数据设计的执行计划可能不如德克萨斯州大小的数据有效。当服务器重新启动时，这可能会产生令人惊讶的结果，因为新生成的执行计划将针对首先使用的任何参数 - 不一定是最好的参数。除非有重大原因，例如重建统计数据，否则该计划不会重新编译。
这就是查询计划的用武之地，SQL Server 2008 提供了许多新功能，可以帮助 DBA 长期固定特定的查询计划，无论首先调用什么参数。
我担心的是，当您重建存储过程时，您强制执行计划重新编译。你用你最喜欢的参数调用它，然后当然它很快 - 但问题可能不是存储过程。存储过程可能在某个时刻使用一组不寻常的参数重新编译，因此查询计划效率低下。您可能没有修复任何问题，并且下次服务器重新启动或重新编译查询计划时您可能会遇到相同的问题。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
