Azure SQL 查詢永遠不會完成

我遇到了一個執行和執行但從未完成的 SQL 查詢的問題。該數據庫是 Azure SQL 數據庫。

我的表有幾千萬行，看起來像這樣：

CREATE TABLE [dbo].[MyData](
[CustomerId] [int] NOT NULL,
[TagName] [nvarchar](100) NOT NULL,
[TagValue] [real] NULL,
[TimeStamp] [datetime2](7) NOT NULL,
[status] [int] NULL,
CONSTRAINT [PK_MyData] PRIMARY KEY CLUSTERED 
(
 [CustomerId] ASC,
 [TagName] ASC,
 [TimeStamp] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, 
ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
)

我的選擇語句如下所示：

DECLARE @StartDate as datetime
DECLARE @EndDate as datetime

Select @StartDate = LastReadDT from MyData_LastDT_Read
Select @EndDate = dateadd(minute,30,@StartDate)

SELECT   CAST([TagName] as varchar(100)) as [tag], 
        CAST(isnull(TagValue, 0) as real) as tagvalue, 
        CAST([TimeStamp] as datetime) as [DataTimeStamp], 
        CAST(192 as int) as [status]
FROM     [dbo].[MyData]
where    CustomerID = 1 
and      TimeStamp <= @EndDate 
and      TimeStamp > @StartDate
order by TimeStamp asc

奇怪的是，如果我刪除@StartDateand@EndDate變數，而只是硬編碼TimeStampwhere 子句中的實際值，查詢將在不到 1 秒的時間內返回結果。與變數相比，為什麼TimeStamp對查詢中的值進行硬編碼會產生如此巨大的差異？關於如何提高性能的任何建議？不幸的是，我需要使用變數，因為這個查詢在不同的時間範圍內重複執行。

這有點參數嗅探問題的味道。看看我在那裡做了什麼？小屁孩，對吧？

無論如何，Paul White 寫了一篇很棒的文章，介紹了解決這個問題的各種方法，所以當你應該閱讀他的文章時，我不會詳細介紹。不過，由於這是一個臨時聲明，您可以快速嘗試使用OPTION (RECOMPILE)提示強制重新編譯。如果這解決了您的問題，那麼您肯定會遇到我懷疑的問題。但是，正確解決此問題的最佳方法是將您的語句轉換為儲存過程，然後執行傳入日期參數的儲存過程。參數化的儲存過程不會成為目前問題的犧牲品，也應該是可重用的。

引用自：https://dba.stackexchange.com/questions/176915