Quick SELECT 有时会超时
Quick SELECT sometimes time out
我有执行简单 select 的存储过程。任何时候我手动 运行 它,它 运行 秒下。但是在生产中(SQL Azure S2 数据库)它每 12 个我们的计划任务中 运行s - 所以我认为每次使用 "cold" 期望它 运行 是合理的- 没有缓存数据。而且性能非常难以预测 - 有时需要 5 秒,有时需要 30 秒,有时甚至需要 100 秒。
select 被优化到最大(无论如何,据我所知)- 我创建了过滤索引,包括从 SELECT 返回的所有列,所以执行计划中唯一的操作是索引扫描.估计行数和实际行数之间存在巨大差异:
但总的来说,查询似乎很轻量级。我不责怪环境 (SQL Azure),因为有很多查询一直在执行,而这个是唯一一个有这个性能问题的查询。
这是 XML 愿意提供帮助的 SQL 忍者的执行计划:http://pastebin.com/u5GCz0vW
编辑:
Table结构:
CREATE TABLE [myproject].[Purchase](
[Id] [int] IDENTITY(1,1) NOT NULL,
[ProductId] [nvarchar](50) NOT NULL,
[DeviceId] [nvarchar](255) NOT NULL,
[UserId] [nvarchar](255) NOT NULL,
[Receipt] [nvarchar](max) NULL,
[AppVersion] [nvarchar](50) NOT NULL,
[OSType] [tinyint] NOT NULL,
[IP] [nchar](15) NOT NULL,
[CreatedOn] [datetime] NOT NULL,
[ValidationState] [smallint] NOT NULL,
[ValidationInfo] [nvarchar](max) NULL,
[ValidationError] [nvarchar](max) NULL,
[ValidatedOn] [datetime] NULL,
[PurchaseId] [nvarchar](255) NULL,
[PurchaseDate] [datetime] NULL,
[ExpirationDate] [datetime] NULL,
CONSTRAINT [PK_Purchase] PRIMARY KEY CLUSTERED
(
[Id] ASC
)
索引定义:
CREATE NONCLUSTERED INDEX [IX_AndroidRevalidationTargets3] ON [myproject].[Purchase]
(
[ExpirationDate] ASC,
[ValidatedOn] ASC
)
INCLUDE ( [ProductId],
[DeviceId],
[UserId],
[Receipt],
[AppVersion],
[OSType],
[IP],
[CreatedOn],
[ValidationState],
[ValidationInfo],
[ValidationError],
[PurchaseId],
[PurchaseDate])
WHERE ([OSType]=(1) AND [ProductId] IS NOT NULL AND [ProductId]<>'trial' AND ([ValidationState] IN ((1), (0), (-2))))
数据属于敏感数据,无法提供样本。
由于您的查询 returns 只有 1 个匹配项,我认为您应该 trim 将索引降低到最低限度。您可以通过聚集索引中的键查找获取剩余的列:
CREATE NONCLUSTERED INDEX [IX_AndroidRevalidationTargets3] ON [myproject].[Purchase]
(
[ExpirationDate] ASC,
[ValidatedOn] ASC
)
WHERE ([OSType]=(1) AND [ProductId] IS NOT NULL AND [ProductId]<>'trial' AND ([ValidationState] IN ((1), (0), (-2))))
这并没有消除扫描,但它使索引更精简以便于快速读取。
编辑: OP 声明精简索引被 SQL 服务器忽略。您可以强制 SQL 服务器使用过滤器索引:
SELECT *
FROM [myproject].[Purchase] WITH (INDEX(IX_AndroidRevalidationTargets3))
我有执行简单 select 的存储过程。任何时候我手动 运行 它,它 运行 秒下。但是在生产中(SQL Azure S2 数据库)它每 12 个我们的计划任务中 运行s - 所以我认为每次使用 "cold" 期望它 运行 是合理的- 没有缓存数据。而且性能非常难以预测 - 有时需要 5 秒,有时需要 30 秒,有时甚至需要 100 秒。
select 被优化到最大(无论如何,据我所知)- 我创建了过滤索引,包括从 SELECT 返回的所有列,所以执行计划中唯一的操作是索引扫描.估计行数和实际行数之间存在巨大差异:
但总的来说,查询似乎很轻量级。我不责怪环境 (SQL Azure),因为有很多查询一直在执行,而这个是唯一一个有这个性能问题的查询。
这是 XML 愿意提供帮助的 SQL 忍者的执行计划:http://pastebin.com/u5GCz0vW
编辑:
Table结构:
CREATE TABLE [myproject].[Purchase](
[Id] [int] IDENTITY(1,1) NOT NULL,
[ProductId] [nvarchar](50) NOT NULL,
[DeviceId] [nvarchar](255) NOT NULL,
[UserId] [nvarchar](255) NOT NULL,
[Receipt] [nvarchar](max) NULL,
[AppVersion] [nvarchar](50) NOT NULL,
[OSType] [tinyint] NOT NULL,
[IP] [nchar](15) NOT NULL,
[CreatedOn] [datetime] NOT NULL,
[ValidationState] [smallint] NOT NULL,
[ValidationInfo] [nvarchar](max) NULL,
[ValidationError] [nvarchar](max) NULL,
[ValidatedOn] [datetime] NULL,
[PurchaseId] [nvarchar](255) NULL,
[PurchaseDate] [datetime] NULL,
[ExpirationDate] [datetime] NULL,
CONSTRAINT [PK_Purchase] PRIMARY KEY CLUSTERED
(
[Id] ASC
)
索引定义:
CREATE NONCLUSTERED INDEX [IX_AndroidRevalidationTargets3] ON [myproject].[Purchase]
(
[ExpirationDate] ASC,
[ValidatedOn] ASC
)
INCLUDE ( [ProductId],
[DeviceId],
[UserId],
[Receipt],
[AppVersion],
[OSType],
[IP],
[CreatedOn],
[ValidationState],
[ValidationInfo],
[ValidationError],
[PurchaseId],
[PurchaseDate])
WHERE ([OSType]=(1) AND [ProductId] IS NOT NULL AND [ProductId]<>'trial' AND ([ValidationState] IN ((1), (0), (-2))))
数据属于敏感数据,无法提供样本。
由于您的查询 returns 只有 1 个匹配项,我认为您应该 trim 将索引降低到最低限度。您可以通过聚集索引中的键查找获取剩余的列:
CREATE NONCLUSTERED INDEX [IX_AndroidRevalidationTargets3] ON [myproject].[Purchase]
(
[ExpirationDate] ASC,
[ValidatedOn] ASC
)
WHERE ([OSType]=(1) AND [ProductId] IS NOT NULL AND [ProductId]<>'trial' AND ([ValidationState] IN ((1), (0), (-2))))
这并没有消除扫描,但它使索引更精简以便于快速读取。
编辑: OP 声明精简索引被 SQL 服务器忽略。您可以强制 SQL 服务器使用过滤器索引:
SELECT *
FROM [myproject].[Purchase] WITH (INDEX(IX_AndroidRevalidationTargets3))