超時時間已到。 在操作或服務器完成之前經過了超時時間。 等待操作超時-奇怪的行為

Question

我知道SO中有很多這類主題，但想向我介紹一下具體示例。

從Web應用程序（ADO.NET，ASP.NET MVC）運行操作時，出現錯誤： 超時已過期。 在操作或服務器完成之前經過了超時時間。 等待操作超時

但是從第二只手直接在db原始查詢上運行時（由探查器捕獲）僅花費2秒。

背景：

1. 問題突然出現（發布后一周），僅在生產服務器中發生。
2. 此特定查詢的超時為180秒，http請求的超時為24000 [單位]-可能也為秒（每個MSDN）
3. 我們沒有全文索引
4. 當用戶通過一個“文本”（普通文本框）字段進行搜索時，僅針對一個特定查詢會發生錯誤，該查詢會生成具有其他10-12個“或類似％value％”條件的查詢（從一開始就完成該查詢的方式，並具有沒有機會更改它）
5. 奇怪的是，非常相似的查詢（對於其他具有相同“或類似％value％”數量的“自由文本”字段）正常工作
6. 事務隔離級別=序列化
7. 每種查詢的數據綁定方式相同（控制器->服務-> db->服務->視圖模型-> html），實際上我們的框架會自動將字段從“選擇”查詢綁定到viewModels
8. 原始查詢（由Profiler捕獲）正在快速運行（2-3秒），但是從webApp級別返回超時。
9. 我沒有直接訪問產品服務器，所以即時通訊無法立即檢查所有內容，我也無法共享任何代碼/堆棧跟蹤信息。

建議：

找到了很多類似的帖子，這對我來說似乎特別有趣： https : //stackoverflow.com/a/8603111 ，並且想知道有關清除統計信息（exec sp_updatestats）的信息。

題：

您是否有類似的經歷，也許還有以上建議的其他建議？ 原始查詢在短時間內運行但由於webapp超時導致的原因可能是什么？

Answer 1

這很可能是由為不同選項緩存的不同執行計划引起的。

看一下這些問題：

與SSMS相比，通過Entity Framework調用時，存儲過程正在以不同的索引執行

和

與SqlCommand一起使用時，為什么某些sql查詢要慢得多？