非常抱歉，今天早上 6:37~8:15 期間，由于獲取網(wǎng)站首頁博文列表的 SQL 語句出現(xiàn)突發(fā)的查詢超時問題，造成訪問網(wǎng)站首頁時出現(xiàn) 500 錯誤，由此給您帶來麻煩，請您諒解。

故障的情況是這樣的。

故障期間日志中記錄了大量下面的錯誤。

2020-02-03 06:37:24.635 [Error] An unhandled exception has occurred while executing the request./Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddlewareSystem.Data.SqlClient.SqlException (0x80131904): Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. ---> System.ComponentModel.Win32Exception (258): Unknown error 258 at System.Data.SqlClient.SqlCommand.>c.ExecuteDbDataReaderAsync>b__126_0(Task`1 result)

數(shù)據(jù)庫服務(wù)器（阿里云 RDS SQL Server 2016 實例）的 CPU 消耗突增。

數(shù)據(jù)庫服務(wù)器的 IOPS 暴增。

通過阿里云 RDS 控制臺的 CloudDBA 可以查看到故障期間獲取首頁博文的 SQL 語句被執(zhí)行了3萬多次，執(zhí)行這么多次是由于查詢超時，無法建立緩存，每次請求都要訪問數(shù)據(jù)庫。

發(fā)現(xiàn)故障后，我們通過阿里云 RDS 的主備切換恢復(fù)了正常。

經(jīng)過對故障的排查分析，鎖定的最大嫌疑對象是 SQL Server 參數(shù)嗅探（詳見園子里的博文 什么是 SQL Server 參數(shù)嗅探）。

對于這種因為重用他人生成的執(zhí)行計劃而導(dǎo)致的水土不服現(xiàn)象，SQL Server 有一個專有名詞，叫“參數(shù)嗅探 parameter sniffing”。

而且我們找到了引發(fā) SQL Server 參數(shù)嗅探問題的條件。

在我們的 open api 中提供了獲取首頁博文列表的 web api ，但沒有限制可以獲取的最大博文數(shù)，也就是下面的 ItemCount 參數(shù)（除了 open api ，其他地方調(diào)用時 ItemCount 值都是 20 ）。

SELECT TOP (@ItemCount)

假如有人調(diào)用 open api 時給 ItemCount 傳了一個很大的值，比如 20000 ，雖然調(diào)用的是同樣的 SQL 語句，但由于 ItemCount 的值不同， SQL Server 可能會生成相差很大的執(zhí)行計劃，對于 ItemCount 20000 性能比較好的執(zhí)行計劃，對于 ItemCount 20 可能性能極差。如果查詢 ItemCount 20000 時生成的執(zhí)行計劃被緩存下來，查詢 ItemCount 20 時繼續(xù)使用這個執(zhí)行計劃，就會出現(xiàn)本來好好的 SQL 查詢突然變得性能極差。我們今天遇到的故障很可能就是這個原因，而且故障時就一個 SQL 語句出現(xiàn)問題（正好就這個 SQL 查詢緩存了水土不服的執(zhí)行計劃），其他都正常，也驗證了這個猜測。

通過這次故障，我們吸取的教訓是一定要在代碼中對 ItemCount 與 PageSize 的最大值進行限制，它不僅僅是帶來不必要的低性能查詢，而且可能會因為 SQL Server 參數(shù)嗅探問題拖垮整個數(shù)據(jù)庫。

總結(jié)

以上所述是小編給大家介紹的SQL語句執(zhí)行超時引發(fā)網(wǎng)站首頁訪問故障問題，希望對大家有所幫助！