如何解決SQL語句中執(zhí)行超時引發(fā)網(wǎng)站首頁訪問故障的問題

這篇文章將為大家詳細講解有關(guān)如何解決SQL語句中執(zhí)行超時引發(fā)網(wǎng)站首頁訪問故障的問題，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

故障的情況是這樣的。

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

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 的主備切換恢復了正常。

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

對于這種因為重用他人生成的執(zhí)行計劃而導致的水土不服現(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ù)庫。

關(guān)于“如何解決SQL語句中執(zhí)行超時引發(fā)網(wǎng)站首頁訪問故障的問題”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。