Question

我有一个SQL Tabe＆＃34; Document＆＃34;它包含很多行（最多几百万）。

当我执行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

问题是，我在LightSpeed（c＃中的数据库OR-Mapper）30秒后得到Timeout-Exception。

有人可以帮我吗？

编辑：

这是我们自动由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-Update大约需要35秒才能执行。通常此更新仅需0.3秒。似乎另一个进程阻止了这个。我看到了一些其他的选择，这些选择在此更新过程中开始，一直等到更新完成，直到完成select-execution。

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

由于托比

Answer 1

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

我会从：

开始

检查document表有多少索引（但很难相信更新索引会花费这么多时间）。
检查更新时是否执行了任何触发器。

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

另一个原因可能是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_是完全错误的。

它包含许多可能使更新变慢的列。

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

可能它应该与以state列开头的其他索引相结合 - 我假设state只有几个值。

不幸的是，我无法以文本格式解释执行计划。

Answer 2

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

尝试删除不必要的索引。

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

SQL Update非常慢（大约20-50秒），Select只需不到1秒

3 个答案:

更新