表值函数确实存在奇怪的问题
当我尝试调用特定的存储过程时，我的应用程序出现一些超时。我将其隔离到一个特定的存储过程中，发现当我使用参数调用该存储过程中的表值函数时，它需要永远运行。但如果我传入一个特定的值（如 804），它会很快返回。
如果我使用参数单独运行它，它运行得很好，但是当我使用参数将它添加回查询时，它会永远运行......然后用静态值交换参数，它运行得很快？
我已采取的步骤：
- 删除程序并重新创建。
- 对包含类似查询字符串的所有计划运行
DBCC FREEPROCCACHE。 - 只是一个测试数据库，所以我用昨晚的备份恢复了数据库。
还有一点需要注意。在同一服务器上的另一个数据库上......大约相同数量的数据运行良好......非常奇怪。
我在忽略什么？我真的不明白。
I was getting some timeouts on my app when I was trying to call a specific stored procedure. I isolated it down to a specific sproc and found that when I call a tablevalued function in that sproc with a parameter it takes forever to run. But if I pass in a specific value (like 804) it will return quickly.
If I run it by itself with the parameter it runs fine, but when I add it back into the query with the parameter it runs forever....then swap out the param with a static value and it runs quickly?
Steps I have taken:
- Dropped procedure and recreated.
- Ran
DBCC FREEPROCCACHEon all plans containing a similar query string. - Just a test db so I restored the db with last nights backup.
Another thing to note. On another db on the same server...about the same amount of data it runs fine......very strange.
What am I overlooking? I really don't get it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
参数嗅探？
很抱歉简短的回答，但值得阅读一些答案...
我之前也有
Parameter sniffing?
Sorry for the short answer, but worth reading some answers...
From me previously too