sql-server - SQL Server 不在存储过程中使用索引

Question

我还没有通过使用存储过程解决这个问题，但我们决定超越SP，只执行普通的SQL

请看下面的扩展表方案
编辑 2:更新索引(不再使用 actieGroep)
注意。 SQL Server 2005 企业版 9.00.4035.00
NB2。似乎与 http://www.sqlservercentral.com/Forums/Topic781451-338-1.aspx 有关

我在一张 table 上有两个索引:

statistiekId 上的聚集 PK 索引

foreignId 上的非聚集索引

我有以下代码:

DECLARE @fid BIGINT
SET @fid = 873926

SELECT foreignId
FROM STAT_Statistieken
WHERE foreignId = @fid

这只是按照它应该的方式执行；它指向正确的索引，它所做的就是扫描索引。

现在我正在创建一个存储过程:

ALTER PROCEDURE MyProcedure (@fid BIGINT)
AS BEGIN
    SELECT foreignId
    FROM STAT_Statistieken
    WHERE foreignId = @fid
END

运行的东西:

EXEC MyProcedure @fid = 873926

现在它正在运行 对我的 PK 索引进行聚集索引扫描 ! wtf是怎么回事？

所以我把SP改成

SELECT foreignId
FROM STAT_Statistieken
    WITH (INDEX(IX_STAT_Statistieken_2))
WHERE foreignId = @fid

现在它给出了:由于此查询中定义的提示，查询处理器无法生成查询计划。在不指定任何提示且不使用 SET FORCEPLAN 的情况下重新提交查询。虽然相同的函数在直接执行时就像它应该运行的那样运行。

额外信息:可以重现此行为的完整方案(评论中的英文名称)

表

CREATE TABLE [dbo].[STAT_Statistieken](
    [statistiekId] [bigint] IDENTITY(1,1) NOT NULL,
    [foreignId] [bigint] NOT NULL,
    [datum] [datetime] NOT NULL, --date
    [websiteId] [int] NOT NULL,
    [actieId] [int] NOT NULL, --actionId
    [objectSoortId] [int] NOT NULL, --kindOfObjectId
    [aantal] [bigint] NOT NULL, --count
    [secondaryId] [int] NOT NULL DEFAULT ((0)),
    [dagnummer]  AS (datediff(day,CONVERT([datetime],'2009-01-01 00:00:00.000',(121)),[datum])) PERSISTED, --daynumber
    [actieGroep]  AS (substring(CONVERT([varchar](4),[actieId],0),(1),(1))) PERSISTED,
    CONSTRAINT [STAT_Statistieken_PK] PRIMARY KEY CLUSTERED --actionGroup
    (
        [statistiekId] ASC
    )WITH (PAD_INDEX  = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]
    ) ON [PRIMARY]

索引

CREATE NONCLUSTERED INDEX [IX_STAT_Statistieken_foreignId_dagnummer_actieId_secondaryId] ON [dbo].[STAT_Statistieken] 
(
    [foreignId] ASC,
    [dagnummer] ASC,
    [actieId] ASC,
    [secondaryId] ASC
)WITH (PAD_INDEX  = ON, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, IGNORE_DUP_KEY = OFF, FILLFACTOR = 80, ONLINE = OFF) ON [PRIMARY]

执行

SET NOCOUNT ON;

    DECLARE @maand INT, @jaar INT, @foreignId BIGINT
    SET @maand = 9
    SET @jaar = 2009
    SET @foreignId = 828319


DECLARE @startDate datetime, @endDate datetime
SET @startDate = DATEADD(month, -1, CONVERT(datetime,CAST(@maand AS varchar(3))+'-01-'+CAST(@jaar AS varchar(5))))
SET @endDate = DATEADD(month, 1, CONVERT(datetime,CAST(@maand AS varchar(3))+'-01-'+CAST(@jaar AS varchar(5))))

DECLARE @firstDayDezeMaand datetime
SET @firstDayDezeMaand = CONVERT(datetime, CAST(@jaar AS VARCHAR(4)) + '/' + CAST(@maand AS VARCHAR(2)) + '/1')

DECLARE @daynumberFirst int
set @daynumberFirst = DATEDIFF(day, '2009/01/01', @firstDayDezeMaand)

DECLARE @startDiff int
SET @startDiff = DATEDIFF(day, '2009/01/01', @startDate)

DECLARE @endDiff int
SET @endDiff = DATEDIFF(day, '2009/01/01', @endDate)

SELECT @foreignId AS foreignId,
    SUM(CASE WHEN dagnummer >= @daynumberFirst THEN (CASE WHEN actieId BETWEEN 100 AND 199 THEN aantal ELSE 0 END) ELSE 0 END) as aantalGevonden, 
    SUM(CASE WHEN dagnummer >= @daynumberFirst THEN (CASE WHEN actieId BETWEEN 200 AND 299 THEN aantal ELSE 0 END) ELSE 0 END) as aantalBekeken, 
    SUM(CASE WHEN dagnummer >= @daynumberFirst THEN (CASE WHEN actieId BETWEEN 300 AND 399 THEN aantal ELSE 0 END) ELSE 0 END) as aantalContact,
    SUM(CASE WHEN dagnummer < @daynumberFirst THEN (CASE WHEN actieId BETWEEN 100 AND 199 THEN aantal ELSE 0 END) ELSE 0 END) as aantalGevondenVorige, 
    SUM(CASE WHEN dagnummer < @daynumberFirst THEN (CASE WHEN actieId BETWEEN 200 AND 299 THEN aantal ELSE 0 END) ELSE 0 END) as aantalBekekenVorige, 
    SUM(CASE WHEN dagnummer < @daynumberFirst THEN (CASE WHEN actieId BETWEEN 300 AND 399 THEN aantal ELSE 0 END) ELSE 0 END) as aantalContactVorige
FROM STAT_Statistieken
WHERE
    dagnummer >= @startDiff
    AND dagnummer < @endDiff
    AND foreignId = @foreignId 
OPTION(OPTIMIZE FOR (@foreignId = 837334, @startDiff = 200, @endDiff = 300))

DBCC统计

Name                                                          | Updated               | Rows      | Rows smpl | Steps | Density | Avg. key | String index
IX_STAT_Statistieken_foreignId_dagnummer_actieId_secondaryId    Oct  6 2009  3:46PM 1245058    1245058    92    0,2492834    28    NO

All Density  | Avg. Length | Columns
3,227035E-06    8    foreignId
2,905271E-06    12    foreignId, dagnummer
2,623274E-06    16    foreignId, dagnummer, actieId
2,623205E-06    20    foreignId, dagnummer, actieId, secondaryId
8,031755E-07    28    foreignId, dagnummer, actieId, secondaryId, statistiekId

RANGE HI | RANGE_ROWS | EQ_ROWS | DISTINCT_RANGE_ROWS | AVG_RANGE ROWS
-1         0            2         0                     1
1356       3563         38        1297                  2,747109
8455       14300        29        6761                  2,115072

并且索引的使用如执行计划中所示。当我用这个参数将它包装在一个过程中时:

@foreignId bigint,
@maand int, --month
@jaar int --year

并使用 _SP_TEMP @foreignId = 873924, @maand = 9, @jaar = 2009 运行它

它进行聚集索引扫描!

Answer 1

[编辑]

下面的 PERSISTED-not-being-used 问题仅发生在我的系统 (SQL 2008) 上的 actieGroep/actieId 中。但是，同样的问题也可能发生在带有 dagnummer/datum 列的 SQL 2005 系统上。如果确实发生了这种情况，它将解释您所看到的行为，因为需要进行聚集索引扫描来过滤数据值。要诊断是否确实发生了这种情况，只需将数据列作为 INCLUDE-d 列添加到您的索引中，如下所示:

CREATE NONCLUSTERED INDEX [IX_STAT_Statistieken_1] ON [dbo].[STAT_Statistieken]  
(  
    [foreignId] DESC,  
    [dagnummer] DESC,  
    [actieId] ASC,   
    [aantal] ASC    
) INCLUDE (datum)  ON [PRIMARY]

如果此索引修订版问题消失，那么您就知道 dagnummer 是问题所在——您甚至可以从索引中删除 dagnummer，因为 SQL 无论如何都不使用它。

此外，修改您的索引以添加 actieId 是一个好主意，因为它避免了下面提到的问题。但是在这个过程中你还需要把aantal列留在索引中，这样你的索引就会是covering index对于这个查询。否则 SQL 将不得不读取您的聚集索引以获取该列的值。这会减慢您的查询速度，因为对聚集索引的查找非常缓慢。

[结束编辑]

这里有一堆想法可以帮助您解决这个问题，首先是最有可能/最简单的事情:

当我尝试重现您的使用架构和查询(使用假生成的数据)时，我看到您的 PERSISTED 计算列 actieGroep 在运行时被重新计算，而不是使用的持久值。这看起来像是 SQL Server 优化器中的一个错误。由于基础列值 actieGroep 不存在于您的覆盖索引中 IX_STAT_Statistieken_1索引(只有计算列在那里)，如果 SQL Server 决定它需要获取额外的列，SQL 可能会认为聚集索引比使用非聚集索引便宜，然后为每个匹配的行查找 actieId集群索引。这是因为聚集索引查找相对于顺序 I/O 来说非常昂贵，因此任何需要查找超过百分之几的行的计划可能比扫描更便宜。在任何情况下，如果这确实是您看到的问题，那么将 actieGroep 添加为您的 IX_STAT_Statistieken_1 的 INCLUDE-d 列。 index 应该可以解决这个问题。像这样:
CREATE NONCLUSTERED INDEX [IX_STAT_Statistieken_1] ON [dbo].[STAT_Statistieken]
(
[foreignId] DESC,
[secondaryId] ASC,
[actieGroep] ASC,
[dagnummer] DESC,
[aantal] ASC
) INCLUDE (actieId) ON [PRIMARY]

计算列 actieGroep 的数据类型是字符串，但您在 WHERE 子句和 CASE 语句中将其与整数(例如 IN (1,2,3))进行比较。如果 SQL 决定转换列而不是常量，则会损害查询性能并可能使计算列扩展问题(如上所述)更有可能发生。我强烈建议将您的计算列定义更改为整数类型，例如
CASE WHEN actieId BETWEEN 0 AND 9 THEN actieId
WHEN actieId BETWEEN 10 AND 99 THEN actieId/10
WHEN actieId BETWEEN 100 AND 999 THEN actieId/100
WHEN actieId BETWEEN 1000 AND 9999 THEN actieId/1000
WHEN actieId BETWEEN 10000 AND 99999 THEN actieId/10000
WHEN actieId BETWEEN 100000 AND 999999 THEN actieId/100000
WHEN actieId BETWEEN 1000000 AND 9999999 THEN actieId/1000000
ELSE actieId/10000000 END

您正在对只有一个可能值的列进行 GROUP BY。因此，不需要 GROUP BY。希望优化器能够足够聪明地知道这一点，但您永远无法确定。

尝试使用 OPTIMIZE FOR 提示而不是直接强制索引，这可能会解决您在提示中遇到的错误

克雷格·弗里德曼 (Craig Freedman) 的帖子 http://blogs.msdn.com/craigfr/archive/2009/04/28/implied-predicates-and-query-hints.aspx它描述了在使用 RECOMPILE 时收到的与提示相关的错误消息的常见原因。您可能需要查看该帖子并确保您正在运行 SQL Server 的最新更新。

我确定您已经这样做了，但是您可能希望通过执行我们正在做的事情来构建数据的“洁净室”版本:创建新数据库，在您的问题中使用 DDL 创建表，然后用数据填充表。如果您得到的结果不同，请查看实际表和索引中的架构，看看它们是否不同。

如果这些都不起作用，请发表评论，我可以提出一些更疯狂的想法。 :-)

另外，请将 SQL Server 的确切版本和更新级别添加到您的问题中!