SQL 超时和索引答案

【问题标题】：SQL Timeout and indicesSQL 超时和索引
【发布时间】：2010-07-20 07:41:40
【问题描述】：

在包含几十个表的数据库中更改和查找内容，其中大表中有大约 50 万行我经常遇到超时。

其中一些超时我不明白。例如我得到了这张表：

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

当我像这样在此表中搜索项目时（在插入大量项目期间）时，我经常遇到超时：

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

搜索唯一约束时的这些超时经常发生。我期望独特的约束具有与索引相同的好处，我弄错了吗？我也需要这些字段的索引吗？
还是我必须进行不同的搜索才能受益于约束？

我使用的是 SQL Server 2008 R2。

【问题讨论】：

是@Search1 和@Search2 NVARCHAR 吗？如果它们不是 Unicode 字符串，那么我之前见过这种事情（排序规则不匹配）导致此类性能问题。

标签： performance tsql sql-server-2008 indexing

【解决方案1】：

唯一约束创建一个索引。根据查询和定义的约束，您应该处于覆盖情况，这意味着索引提供了查询所需的一切，而无需返回集群或堆来检索数据。我怀疑您的索引没有足够的选择性，或者您的统计数据已过时。首先尝试使用 sp_updatestats 更新统计信息。如果这不会改变行为，请尝试使用 UPDATE STATISTICS VPI_APO WITH FULL SCAN。如果这些都不起作用，则需要使用 DBCC SHOW_STATISTICS 检查索引的选择性。

【讨论】：

【解决方案2】：

我的第一个想法是参数嗅探。

如果您使用的是 SQL Server 2008，请尝试“OPTIMIZE FOR UNKNOWN”而不是参数屏蔽

第二个想法是更改索引的唯一常量并显式包含键列。在内部它们是相同的，但作为索引，您具有更大的灵活性（例如过滤器、包含等）

【讨论】：

可能就是这样。当我开始时，数据库甚至可能是空的，这可能会生成一个与以后需要的完全不同的执行计划。