SQL超時和索引

在一個數據庫中更改和查找包含幾十萬行的數據庫中的數據，這些數據在我經常遇到超時的大數據行中有大約50萬行。SQL超時和索引

其中一些超時我不明白。例如，我得到這個表：

SELECT [Key] FROM dbo.[VPI_APO] WHERE ([PZN] = @Search1) AND ([Key_INB] = @Search2)

這些超時在搜索時：

CREATE TABLE dbo.[VPI_APO] 
(
    [Key] bigint IDENTITY(1,1) NOT NULL CONSTRAINT [PK_VPI_APO] PRIMARY KEY, 
    [PZN] nvarchar(7) NOT NULL, 
    [Key_INB] nvarchar(5) NOT NULL, 
) ON [PRIMARY] 
GO 

ALTER TABLE dbo.[VPI_APO] ADD CONSTRAINT [IX_VPI_APOKey_INB] UNIQUE NONCLUSTERED 
(
    [PZN], 
    [Key_INB] 
) ON [PRIMARY] 
GO

我常常當我在這個表像這樣的搜索項超時（插入大體積物品的過程中）獨特的約束經常發生。我認爲獨特的約束與索引具有相同的好處，我誤解了嗎？我是否也需要在這些領域的索引？
或者我將不得不以不同方式搜索以獲得約束？

我正在使用SQL Server 2008 R2。

來源

2010-07-20 Sam

「@ Search1」和「@ Search2' NVARCHAR？如果它們不是Unicode字符串，那麼我就會看到之前導致此類性能問題的這類事情（排序規則不匹配）。 – 2010-07-20 12:19:52

一個唯一的約束創建一個索引。基於查詢和定義的約束，您應該處於一種覆蓋的情況，這意味着索引提供查詢所需的所有內容，而無需返回到羣集或堆以檢索數據。我懷疑你的索引沒有足夠的選擇性，或者你的統計數據已經過時。首先嚐試使用sp_updatestats更新統計信息。如果這不會改變行爲，請嘗試使用UPDATE STATISTICS VPI_APO WITH FULL SCAN。如果這兩者都不起作用，則需要使用DBCC SHOW_STATISTICS檢查索引的選擇性。

來源

2010-07-20 12:02:27 ScaryDBA

我的第一個想法是參數嗅探。

如果你是SQL Server 2008上，嘗試「OPTIMIZE FOR UNKNOWN」，而不是掩蓋參數

第二個想到的就是改變獨特constrant一個索引，並明確包括鍵列。在內部它們是相同的，但作爲一個索引，你有更多的靈活性（例如過濾器，包括等）

來源

2010-07-20 07:47:49 gbn

可能就是這樣。當我開始時，數據庫可能甚至是空的，這可能會產生一個完全不同的執行計劃，這比以後所需的執行計劃要多。 – Sam 2010-07-20 08:04:57

SQL超時和索引

回答

相關問題