Много обновлений для большого стола. Как ускорить? - PullRequest
Новая
       25

Много обновлений для большого стола. Как ускорить?

0 голосов
/ 04 июля 2019

У меня большая таблица (60 столбцов, 2 миллиона строк).

Сначала создается рекурсивный запрос, а затем большинство столбцов обновляются по-своему. Все это обновление довольно медленное (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;

Ответы [ 2 ]

0 голосов
/ 05 июля 2019 
--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%

0 голосов
/ 05 июля 2019

Если честно, мне немного сложно понять, в чем цель.Если Вы вычисляете что-то большое из всех столбцов, возможно, Вы могли бы использовать какую-то большую хранимую процедуру для всех вычислений, и, возможно, таким образом Вы сможете уменьшить количество обновлений.

В любом случае ... также, поскольку скорость является параметромВы ищете, а не количество места, тогда Вы рассматривали индексирование?Если у вас много обновлений, вы можете рассмотреть некластеризованный индекс, это наверняка всегда «ускорит»:).

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

...