查询计划更新具有奇怪的行为

发布于 2025-01-25 18:20:25 字数 2224 浏览 4 评论 0原文

我的表定义为下面的脚本

CREATE TABLE Schema1.Object1(
    Column1 [int] IDENTITY(1,1) NOT NULL,
    Column2 [int] NOT NULL,
    Column3 [int] NOT NULL,
    Column4 [varchar](255) NOT NULL,
    Column5 [varchar](15) NOT NULL,
    Column6 [varchar](255) NOT NULL,
    Column7 [varchar](100) NOT NULL,
    Column8 [varchar](50) NOT NULL,
    Column9 [varchar](50) NOT NULL,
    Column10 [varchar](100) NOT NULL,
    Column11 [varchar](50) NOT NULL,
    Column12 [varchar](50) NOT NULL,
    Column13 [date] NOT NULL,
    Column14 [int] NOT NULL,
    Column15 [date] NOT NULL,
    Column16 [int] NOT NULL,
    Column17 [date] NOT NULL,
    Column18 [int] NOT NULL,
    Column19 [varchar](255) NOT NULL,
    Column20 [tinyint] NOT NULL,
    Column21 [varchar](100) NOT NULL,
    Column22 [varchar](30) NOT NULL,
    Column23 [tinyint] NULL,
 CONSTRAINT [Object1_key0] PRIMARY KEY CLUSTERED 
(
    Column1 ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = ?) ON Column24
) ON Column24
GO

CREATE NONCLUSTERED INDEX [Object1_custom1] ON Schema1.Object1
(
    Column5 ASC
)
INCLUDE(Column1,Column13) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = ?) ON Column24
GO

,我创建了一个索引视图。

我使用下面的脚本更新我的表。

(@0 varchar(15),@1 datetime2(7),@2 datetime2(7),@3 int,@4 varchar(100),@5 int)
UPDATE [Object1]
SET [Column5] = @0, [Column13] = @1, [Column14] = @2, [Column15] = @3, [Column21] = @4
WHERE ([Column1] = @5)

我希望第一个查询计划,但是从昨天开始,我将发现第二个损害更新性能的查询计划。 索引读取以进行视图更新时,它可以按预期工作,是更新表的主要键。当它不起作用时,索引读取是更新列上的索引,是索引扫描。 为什么SQL可以决定在简单的更新中使用第二个计划,因为我仅适用于主钥匙?

”在此处输入图像说明”

I have a table defined as the script below

CREATE TABLE Schema1.Object1(
    Column1 [int] IDENTITY(1,1) NOT NULL,
    Column2 [int] NOT NULL,
    Column3 [int] NOT NULL,
    Column4 [varchar](255) NOT NULL,
    Column5 [varchar](15) NOT NULL,
    Column6 [varchar](255) NOT NULL,
    Column7 [varchar](100) NOT NULL,
    Column8 [varchar](50) NOT NULL,
    Column9 [varchar](50) NOT NULL,
    Column10 [varchar](100) NOT NULL,
    Column11 [varchar](50) NOT NULL,
    Column12 [varchar](50) NOT NULL,
    Column13 [date] NOT NULL,
    Column14 [int] NOT NULL,
    Column15 [date] NOT NULL,
    Column16 [int] NOT NULL,
    Column17 [date] NOT NULL,
    Column18 [int] NOT NULL,
    Column19 [varchar](255) NOT NULL,
    Column20 [tinyint] NOT NULL,
    Column21 [varchar](100) NOT NULL,
    Column22 [varchar](30) NOT NULL,
    Column23 [tinyint] NULL,
 CONSTRAINT [Object1_key0] PRIMARY KEY CLUSTERED 
(
    Column1 ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = ?) ON Column24
) ON Column24
GO

CREATE NONCLUSTERED INDEX [Object1_custom1] ON Schema1.Object1
(
    Column5 ASC
)
INCLUDE(Column1,Column13) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = ?) ON Column24
GO

On this table I created an indexed view.

I update my table with the script below.

(@0 varchar(15),@1 datetime2(7),@2 datetime2(7),@3 int,@4 varchar(100),@5 int)
UPDATE [Object1]
SET [Column5] = @0, [Column13] = @1, [Column14] = @2, [Column15] = @3, [Column21] = @4
WHERE ([Column1] = @5)

I would expect the first query plan, but from yesterday I'm detecting the second one that hurt the update performance.
The index read for view update, when it works as expected, is the primary key of the updated table. When it doesn't works the index read is the index on the updated column and it's a index scan.
Why SQL can decide to use the second plan in a simple update as mine that works for primary key only?

enter image description here

enter image description here

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。
列表为空,暂无数据
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文