同様の質問がありますが、同じではありません:
次のクエリとフィルター処理されたインデックスがありますが、クエリでフィルター処理されたインデックスを使用できない理由がわかりません。
-クエリ-max
を使用しても、列のみを使用しても、インデックスヒントは好きではありません。
SELECT -- MAX(AC1.changeDate)
AC1.changeDate
FROM [dbo].[applicationStateChange] AS ac1 WITH(INDEX(FI_ASC_ChangeDate))
WHERE ac1.applicationID = 130002
AND AC1.newStatus = 'PLC'
-これはフィルタリングされたインデックスです-このインデックスは上記のクエリを最適化するためのものです
CREATE NONCLUSTERED INDEX FI_ASC_ChangeDate
ON [dbo].[applicationStateChange] ( applicationID DESC)
INCLUDE ( [changeDate] )
WHERE newStatus = 'PLC'
WITH ( PAD_INDEX = OFF, FILLFACTOR = 100 , SORT_IN_TEMPDB = OFF , IGNORE_DUP_KEY = OFF, STATISTICS_NORECOMPUTE = OFF, ONLINE = On,
DROP_EXISTING = ON,
DATA_COMPRESSION=PAGE, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON )
ON [NONCLUSTERED_INDEXES]
index hint
を含むクエリを実行すると、次のエラーメッセージが表示されます。
メッセージ8622、レベル16、状態1、行455このクエリで定義されたヒントのため、クエリプロセッサはクエリプランを作成できませんでした。ヒントを指定せず、SET FORCEPLANを使用せずにクエリを再送信します。
何かを逃しましたか?
-列newStatus
をインデックスに追加しても、インデックスでもインクルードでも問題は解決しませんでした。
CREATE NONCLUSTERED INDEX FI_ASC_ChangeDate
ON [dbo].[applicationStateChange] ( applicationID DESC, newStatus ASC)
INCLUDE ( [changeDate] )
WHERE newStatus = 'PLC'
WITH ( PAD_INDEX = OFF, FILLFACTOR = 100 , SORT_IN_TEMPDB = OFF , IGNORE_DUP_KEY = OFF, STATISTICS_NORECOMPUTE = OFF, ONLINE = On,
DROP_EXISTING = ON,
DATA_COMPRESSION=PAGE, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON )
ON [NONCLUSTERED_INDEXES]
CREATE NONCLUSTERED INDEX FI_ASC_ChangeDate
ON [dbo].[applicationStateChange] ( applicationID DESC)
INCLUDE ( [changeDate],newStatus )
WHERE newStatus = 'PLC'
WITH ( PAD_INDEX = OFF, FILLFACTOR = 100 , SORT_IN_TEMPDB = OFF , IGNORE_DUP_KEY = OFF, STATISTICS_NORECOMPUTE = OFF, ONLINE = On,
DROP_EXISTING = ON,
DATA_COMPRESSION=PAGE, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON )
ON [NONCLUSTERED_INDEXES]
互換モードにできますか?
filter
をインデックスから削除すると、クエリはそれを正常に受け入れることに気づきました。しかし、それは私がそれを望んでいる方法ではありません。
CREATE NONCLUSTERED INDEX FI_ASC_ChangeDate
ON [dbo].[applicationStateChange] ( applicationID DESC,newStatus
)
INCLUDE ( [changeDate])
--WHERE newStatus = 'PLC'
WITH ( PAD_INDEX = OFF, FILLFACTOR = 100 , SORT_IN_TEMPDB = OFF , IGNORE_DUP_KEY = OFF, STATISTICS_NORECOMPUTE = OFF, ONLINE = On,
DROP_EXISTING = ON,
DATA_COMPRESSION=PAGE, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON )
ON [NONCLUSTERED_INDEXES]
問題のテーブルの定義は次のとおりです。
IF OBJECT_ID('[dbo].[applicationStateChange]') IS NOT NULL
DROP TABLE [dbo].[applicationStateChange]
GO
CREATE TABLE [dbo].[applicationStateChange] (
[applicationID] INT NOT NULL,
[changeDate] DATETIME NOT NULL,
[oldStatus] CHAR(3) NULL,
[newStatus] CHAR(3) NULL,
[oldStatusReasonID] INT NULL,
[newStatusReasonID] INT NULL,
[oldStatusReason] VARCHAR(60) NULL,
[newStatusReason] VARCHAR(60) NULL,
[oldOnHold] BIT NULL,
[newOnHold] BIT NULL,
CONSTRAINT [PK_applicationStateChange] PRIMARY KEY CLUSTERED ([applicationID] asc, [changeDate] asc) WITH FILLFACTOR = 90,
CONSTRAINT [FK_applicationStateChange_application] FOREIGN KEY ([applicationID]) REFERENCES [application]([applicationID]))
GO
CREATE NONCLUSTERED INDEX [IX_applicationStateChange_ChangeDate]
ON [dbo].[applicationStateChange] ([changeDate] desc)
CREATE NONCLUSTERED INDEX [FI_ASC_ChangeDate]
ON [dbo].[applicationStateChange] ([applicationID] desc, [changeDate] asc, [newStatus] asc)
WHERE ([newStatus]='PLC')
WITH FILLFACTOR = 100
私が見てきたように this answer クエリにoption(recompile)
を追加すると、インデックスヒントを受け入れて正常に実行されます。
_SELECT MAX(AC1.changeDate)
-- AC1.changeDate
FROM [dbo].[applicationStateChange] AS ac1 WITH(INDEX(FI_ASC_ChangeDate))
WHERE AC1.newStatus = 'PLC'
OPTION (RECOMPILE)
_
それでも同じクエリを実行するとwithout
option(recompile)
で同じエラーが発生します
メッセージ8622、レベル16、状態1、行479このクエリでヒントが定義されているため、クエリプロセッサはクエリプランを作成できませんでした。ヒントを指定せず、SET FORCEPLANを使用せずにクエリを再送信します。
ただし、テスト環境では、次の操作を実行する余裕があり、その後、このフィルター処理されたインデックスで問題は発生しなくなりました。
_ALTER DATABASE [JUNOCORE] SET PARAMETERIZATION SIMPLE;
_
テストでこれを行うという私の決定を裏付けるために、以下の記事を読みました。
SQL Server Simple and Forced Parameterization
これで、LIVEの_[JUNOCORE] database
_も simple parameterization に変更したいと思います
これにより、次の質問が表示されます。
ワークロードまたはクエリプランキャッシュの要素のうち、データベースでの単純なパラメーター化または強制的なパラメーター化を決定するために検討すべき要素はありますか?
このエラーの他の考えられる理由を探している人のために:
私の場合、クエリで同じエラーが発生しましたが、誰かがwith forceeekヒントを使用しました。
最後に、テーブルがHEAP
であることがわかり、Clustered Index
を作成すると問題が解決しました。