对一张大桌子进行大量更新。如何加快速度？答案

【问题标题】：Lots of updates to a large table. How to speed up?对一张大桌子进行大量更新。如何加快速度？
【发布时间】：2019-11-15 12:24:57
【问题描述】：

我有一张大表（60 列，200 万行）。

它首先由递归查询构建，然后大多数列以自己的方式更新。所有这些更新都非常缓慢（全球持续时间的 80%）。

更新的顺序不能完全随机，因为某些列用作其他列计算的输入。但是订单在某种程度上是免费的。

将 UPDATE 列表替换为大型 SELECT CASE 是否常见？目前我有这样的事情：

UPDATE t SET col1=col2/col3 WHERE col4 IS NULL AND col5 IS NOT NULL; --UPDATE Nr1

UPDATE t SET col23=col24+col25 WHERE col26 IS NULL; --UPDATE Nr2

...

UPDATE t SET col46=col47*col48 WHERE col1 IS NULL --UPDATE Nr50

可以用类似的东西代替吗：

CREATE TABLE t2 AS
SELECT
CASE WHEN col4 IS NULL AND col5 IS NOT NULL THEN col2/col3 ELSE col1 END AS col1,
...
CASE WHEN col26 IS NULL THEN col24+col25 ELSE col23 END AS col23,
..
FROM t;

CREATE TABLE t3 AS
SELECT
col1,
col2,...,
CASE WHEN col1 IS NULL THEN col47*col48 ELSE col46 END AS col46
FROM t2;

【问题讨论】：

"How to speed up?" 通过发布表结构、示例数据和更新逻辑。提供dbfiddle.uk 演示和期望的结果将有很大帮助
您能否提供一个简化示例来说明您的实际要求？
看看“计算列”：docs.microsoft.com/en-us/sql/relational-databases/tables/…
听起来架构设计需要重新考虑。

标签： sql sql-server performance

【解决方案1】：

说实话，我有点难以理解目标是什么。如果您要从所有列中计算一些大的东西，也许您可以使用一些大的存储过程来进行所有计算，也许这样您就可以减少更新的数量。

无论如何..由于速度是您正在寻找的参数而不是空间量，那么您是否考虑过索引？如果你有很多更新你可以考虑非聚集索引，这肯定总是“加速”:)。

https://docs.microsoft.com/en-us/sql/relational-databases/indexes/clustered-and-nonclustered-indexes-described?view=sql-server-2017

【讨论】：

【解决方案2】：

--Requete 40. Performance cost: 3%
UPDATE #temp_arbo_of_3
SET PxAchat=NULL, CuTpsAch=NULL
WHERE IdBE IS NULL;


--Requete 41. Performance cost: 2%
UPDATE #temp_arbo_of_3
SET CuTrait = NULL
WHERE IdBE IS NOT NULL;


--Requete 42. Performance cost: 2%
UPDATE #temp_arbo_of_3
SET NrOF_Source = _ofI
WHERE IdBE IS NOT NULL;

现在，如果我将所有这些替换为：

--Requete 40. Performance cost: 3%
UPDATE #temp_arbo_of_3
SET PxAchat=CASE WHEN IdBE IS NULL THEN NULL ELSE PxAchat END,
     CuTpsAch=CASE WHEN IdBE IS NULL THEN NULL ELSE CuTpsAch END,
     CuTrait=CASE WHEN IdBE IS NOT NULL THEN NULL ELSE CuTrait END,
     NrOF_Source=CASE WHEN IdBE IS NOT NULL THEN _ofI ELSE NrOF_source END
WHERE IdBE IS NULL;

性能（如 SQL Server 执行计划所示）更好。 3%+2%+2% > 3%

【讨论】：