SQL Update 真的很慢（大约 20-50 秒），Select 不到 1 秒

Question

我有一个包含很多行（最多几百万行）的 SQL 表“文档”。

当我执行 Select-Statement 时，大约需要 0.5 秒。 但是当我使用相同的 WHERE 子句执行更新时，大约需要 20 到 50 秒，具体取决于受影响的行数。

这是我的数据。

//选择

SELECT * FROM Document 
WHERE (State=20 OR State=23) AND 
LetterClosed IS NOT NULL AND 
TYPE=0 AND
SendLetter=1

//更新

UPDATE Document set State=32 
WHERE (State=20 OR State=23) AND 
LetterClosed IS NOT NULL AND 
TYPE=0 AND
SendLetter=1

OR-Mapper 在内部按如下方式将此更新语句发送到数据库：

exec sp_executesql N'Update
Document
SET
    State=@p4
WHERE
(
  (
    (
      (Document.State = @p0 OR Document.State = @p1) 
      AND Document.LetterClosed IS NOT NULL
    ) 
    AND Document.Type = @p2
  ) 
  AND Document.SendLetter = @p3
)'
,N'@p0 int,@p1 int,@p2 int,@p3 bit,@p4 int',@p0=20,@p1=23,@p2=0,@p3=1,@p4=32

问题是，我在 30 秒后从我的 LightSpeed（C# 中的数据库 OR-Mapper）收到超时异常。

有人可以帮我吗？

编辑：

这是我们由 SQL-Server 自动创建的索引：

CREATE NONCLUSTERED INDEX [_dta_index_Document_9_133575514__K42_1_2_3_4_5_6_7_8_9_11_12_13_14_15_16_17_18_19_20_21_22_23_24_25_26_27_28_29_30_31_32_33_34_] ON [Document] 

(
    [State] ASC
)
INCLUDE ( 
[Id],[DocumentId],[SendLetter],[SendFax],[Archive],[Crm],[Validation],[CreationDate],[PageCount],
[InformationLetter],[TermsOfDelivery],[DeliveryTypeNo],[SeparateDelivery],[FormName],[FormDescription],[TemplateFileName],[RecipientType],
[HealthInsuranceNo],[FamilyHealthInsuranceNo],[PensionInsuranceNo],[EmployerCompanyNo],[RecipientName1],[RecipientName2],[RecipientName3],
[RecipientStreet],[RecipientCountryCode],[RecipientZipCode],[RecipientCity],[RecipientFaxNo],[AuthorId],
[AuthorName],[AuthorEmailAddress],[CostcenterDepartment],[CostcenterDescription],[MandatorNo],[MandatorName],[ControllerId],
[ControllerName],[EditorId],[EditorName],[StateFax],[Editable],[LetterClosedDate],[JobId],[DeliveryId],[DocumentIdExternal],[JobGroupIdExternal],
[GcosyInformed]) WITH (SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY]
go

CREATE NONCLUSTERED INDEX [_dta_index_Document_9_133575514__K2_1_46] ON [Document] 
(
    [DocumentId] ASC
)
INCLUDE ( [Id],
[JobId]) WITH (SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY]
go

CREATE NONCLUSTERED INDEX [_dta_index_Document_9_133575514__K46_K2] ON [Document] 
(
    [JobId] ASC,
    [DocumentId] ASC
)WITH (SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY]
go



CREATE NONCLUSTERED INDEX [Document_State_Id] ON [Document] 
(
    [State] ASC,
    [Id] ASC
)WITH (SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY]
go

CREATE NONCLUSTERED INDEX [Document_State_CreationDate] ON [Document] 
(
    [State] ASC,
    [CreationDate] ASC
)WITH (SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY]
go

编辑 2： 现在我有一个图形执行计划： 执行计划：https://skydrive.live.com/redir?resid=597F6CF1AB696567!444&authkey=!ABq72SAWXOoAXfI

执行计划索引更新详情：https://skydrive.live.com/?cid=597f6cf1ab696567&id=597F6CF1AB696567%21445&sff=1&authkey=!ADDPWvxB2JLLvWo

此 SQL 更新执行大约需要 35 秒。通常这个更新只需要 0,3 秒。似乎另一个进程阻止了这个。我看到其他一些选择在此更新中间开始并等到更新完成，直到他们在那里完成选择执行。

所以看起来索引本身是正确的（通常是 0,3 秒执行）。 所有选择（来自 java/jtds、php、.net）都是隔离级别读取提交的（默认）。它会帮助我在这里将所有选择更改为未提交的读取以避免在索引更新期间出现这种阻塞吗？

谢谢 托比

Answer 1

可能您在表 Document 上有索引。索引使选择更快，但更新/插入/删除操作缓慢。

尝试删除不必要的索引。

Answer 2

没有执行计划，我们只能猜测会发生什么。

我将从：

1. 检查document 表有多少索引（但很难相信更新索引需要这么长时间）。
2. 检查更新时是否执行了任何触发器。

所有这些都应该在执行计划中可见。

另一个原因可能是 SQL 引擎对SELECT 查询有一个执行计划，而对UPDATE 查询有一个不同的执行计划...

更新

查看索引后。

在我看来索引_dta_index_Document_9_133575514__K42_1_2_3_4_5_6_7_8_9_11_12_13_14_15_16_17_18_19_20_21_22_23_24_25_26_27_28_29_30_31_32_33_34_是完全错误的。

它包含很多列，可能会导致更新缓慢。

尝试将其删除或将其替换为 state 列上的 CLUSTERED 索引。 CLUSTERED index* 包括*（可以直接访问）所有记录列，无需额外读取。

可能它应该与以state 列开头的其他索引之一结合使用——我假设state 只有几个值。

很遗憾，我无法以文本格式解释执行计划。

Answer 3

我曾经在 SQL Server 2008 和 SQL Server 2014 链接服务器上遇到过这个问题。对我来说，一个解决方法是将“选择”结果存储到一个临时表中，并使用它来进行更新，而不是同时进行复杂的查询和更新。

在你的情况下，这将是：

--Select

SELECT * FROM Document
into #temp 
WHERE (State=20 OR State=23) AND 
LetterClosed IS NOT NULL AND 
TYPE=0 AND
SendLetter=1

--Update

UPDATE Document set State=32 
from #temp
WHERE #temp.id = Document.id 
--assuming that id is your PK