Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
Всем добра. Имеется процедура, в которой создается и наполняется временная таблица, которая затем "апдейтится". Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Приведены не все поля и формула (SET) естественно более сложная, не суть. В таблице порядка 500 млн строк. Каждый шаг порядка 15 минут (около 200 млн строк затрагивается) Попробовал добавить индексы StoreID и GoodID - заметного прироста не получилось, а вот на построение индекса времени ушло... Вопрос - поможет ли в данном случае добавление ID INT IDENTITY(1,1) PRIMARY KEY? Или нужно дробить запросы на более мелкие (по StoreID или GoodID) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2020, 17:06 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
Oleg_SQLВопрос - поможет ли в данном случае добавление ID INT IDENTITY(1,1) PRIMARY KEY? У вас нет кластерного индекса на таблице? Сначала стоит определиться, у вас соединение долго выполняется или только обновление. Сделайте SELECT вместо UPDATE. Вместо цикла почему не соединяться с календариком понедельников? Это будет одно выполнение вместо десятков. А вообще не очень понятен INNER JOIN таблицы самой с собой по одним и тем же полям. Какой тут смысл, кроме дублирующихся полей и фильтра по дате? Код: sql 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2020, 17:32 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
PizzaPizza, в настоящий момент это куча. смысл цикла что то вроде накопления - берутся данные по неделе и обновляются более поздние данные и так далее... формула сложная (нужна для дальнейшего анализа). Подключиться к календарю нельзя, т.к. требуется сначала обновить данные с учетом 1-й недели, а ЗАТЕМ по 2-й, ЗАТЕМ по 3-й и тд Данные с каждой итерацией меняются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2020, 17:38 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
Oleg_SQL PizzaPizza, в настоящий момент это куча. смысл цикла что то вроде накопления - берутся данные по неделе и обновляются более поздние данные и так далее... формула сложная (нужна для дальнейшего анализа). Подключиться к календарю нельзя, т.к. требуется сначала обновить данные с учетом 1-й недели, а ЗАТЕМ по 2-й, ЗАТЕМ по 3-й и тд Данные с каждой итерацией меняются. Увы и ах. Этот бред ~50 раз напрасно перелопачивает "500 млн строк". Код: sql 1. 2. 3. 4. 5. Пойдите учиться на курсы "SQL для чайников". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2020, 18:11 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
Oleg_SQL PizzaPizza, в настоящий момент это куча. смысл цикла что то вроде накопления - берутся данные по неделе и обновляются более поздние данные и так далее... формула сложная (нужна для дальнейшего анализа). Подключиться к календарю нельзя, т.к. требуется сначала обновить данные с учетом 1-й недели, а ЗАТЕМ по 2-й, ЗАТЕМ по 3-й и тд Данные с каждой итерацией меняются. судя по итерационной модели это больше похоже на нарастающий итог и лечится оконками. но может расчет какой то действительно замысловатый, в таком случае при сканировании больших диапазонов вам может поможет некластерный колоночный индекс. индекс по storeId и GooID делать бессмысленно у вас нет такого предиката позволяющего отсечь из выборки превалирующий объем строк. как мне кажется индекс по dt, StoreId, GoodID больше подходит в этом плане ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2020, 18:20 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
Oleg_SQL смысл цикла что то вроде накопления - берутся данные по неделе и обновляются более поздние данные и так далее... Отдельные индексы по StoreID, GoodID смысла не имеют. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2020, 18:33 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
alexeyvg Oleg_SQL смысл цикла что то вроде накопления - берутся данные по неделе и обновляются более поздние данные и так далее... Отдельные индексы по StoreID, GoodID смысла не имеют. Консилиум у постели мертворожденного? ЗЫ. Прежде чем индексы строгать - запросы надо писать научиться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2020, 18:37 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
Oleg_SQL, правильно ли я понял вы взяли цену в первый понедельник и отняли ее у всех строк с таким StoreID и GoodID с более поздней датой затем вы взяли цену во второй понедельник (судя по всему, уже изменённую) и отняли ее у всех строк с таким StoreID и GoodID с более поздней датой ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2020, 18:57 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
andreymx правильно ли я понял вы взяли цену в первый понедельник и отняли ее у всех строк с таким StoreID и GoodID с более поздней датой затем вы взяли цену во второй понедельник (судя по всему, уже изменённую) и отняли ее у всех строк с таким StoreID и GoodID с более поздней датой Oleg_SQL Приведены не все поля и формула (SET) естественно более сложная ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2020, 19:02 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
Oleg_SQL Вопрос - поможет ли в данном случае добавление ID INT IDENTITY(1,1) PRIMARY KEY? Или нужно дробить запросы на более мелкие (по StoreID или GoodID) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2020, 19:04 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
alexeyvg andreymx правильно ли я понял вы взяли цену в первый понедельник и отняли ее у всех строк с таким StoreID и GoodID с более поздней датой затем вы взяли цену во второй понедельник (судя по всему, уже изменённую) и отняли ее у всех строк с таким StoreID и GoodID с более поздней датой Oleg_SQL Приведены не все поля и формула (SET) естественно более сложная ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2020, 21:59 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
alexeyvg А может, лучше одним запросом, без цикла, перелить данные в другую таблицу, сделав все расчёты, а потом сделать переименование? так данные и перелиты в отдельную временную таблицу [#sales] ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2020, 09:08 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
aleks222 Oleg_SQL PizzaPizza, в настоящий момент это куча. смысл цикла что то вроде накопления - берутся данные по неделе и обновляются более поздние данные и так далее... формула сложная (нужна для дальнейшего анализа). Подключиться к календарю нельзя, т.к. требуется сначала обновить данные с учетом 1-й недели, а ЗАТЕМ по 2-й, ЗАТЕМ по 3-й и тд Данные с каждой итерацией меняются. Увы и ах. Этот бред ~50 раз напрасно перелопачивает "500 млн строк". Код: sql 1. 2. 3. 4. 5. Пойдите учиться на курсы "SQL для чайников". Научитесь ВНИМАТЕЛЬНО читать для начала. Приведены не все поля и формула (SET) естественно более сложная, не суть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2020, 09:12 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
alexeyvg Oleg_SQL смысл цикла что то вроде накопления - берутся данные по неделе и обновляются более поздние данные и так далее... Отдельные индексы по StoreID, GoodID смысла не имеют. Спасибо, попробую. Почему собственно вопрос то и возник - затраты по времени на построение индекса иногда съедают всю выгоду от них (не менее часа, думаю будет длится). И одной только теорией, без пробы не обойтись. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2020, 09:36 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
Oleg_SQL alexeyvg А может, лучше одним запросом, без цикла, перелить данные в другую таблицу, сделав все расчёты, а потом сделать переименование? так данные и перелиты в отдельную временную таблицу [#sales] Или сразу заливайте в эту с расчётом, чего бы сразу не посчитать правильно, зачем потом корректировать? Oleg_SQL Спасибо, попробую. Почему собственно вопрос то и возник - затраты по времени на построение индекса иногда съедают всю выгоду от них (не менее часа, думаю будет длится). И одной только теорией, без пробы не обойтись. Другое дело, что, возможно, логически вычисления очень непростые, и сложно их переделать на один проход. Но другого выхода нет, придётся поскрипеть мозгами, ибо такой апдэйт - это трэш :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2020, 09:56 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
Никакие индексы-шминдексы не помогут, ИМХО. Реально ускориться можно одним способом - как-то реорганизовать работу с данными. Н-р где-то отдельно делать расчеты, а потом накатывать готовые результаты на сабжевую таблицу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2020, 10:21 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
alexeyvg, Алгоритм расчета такой, что однозначно нужно считать каждую неделю с учетом предыдущих данных. Смысл такой, что для каждого товара нужно брать последнюю цену (акцию, кпи, признаки и тп) и на их основе считать показатели для текущей в итерации недели. Последняя цена не всегда на прошлой неделе - может быть и пол года назад. Сейчас берется неделя и апдейтся все последующие данные (от той недели до сегодня) и так далее. Это позволяет избежать эти пропуски - как только есть цена для товара, то для последующих периодов она уже засветится, и будет неизменна до нового значения. Примитивно, но запрос простой, он работает и выдает верный результат. Можно менять данные не для всего периода, а только для конкретной недели - это все будет на порядок быстрее. Как для 500 млн товаров (по точкам) проапдейтить данные на основе последних показателей по каждому я знаю. Но конструкция выборки этих последних данных выглядит более зловеще ))) В любом случае придется попробовать и его. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2020, 10:36 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
Oleg_SQL, У вашего подхода есть две проблемы: 1. Из-за отсутствия ограничений/индексов оптимизатор считает, что одна и та же строка может быть обновлена несколько раз. Поэтому в план будет включено исключение таких дубликатов. 2. Такой update предполагает наличие halloween problem. Соответственно в план будет включена защита, скорее всего в виде Eager Table Spool Если критерий уникальности - (dt, StoreID, GoodID), то сделайте у #sales PK по этим столбцам, dt обязательно должен быть первым. Тогда первая проблема отпадет. Для избавления от второй, предварительно отбирайте строки по dt = @dt во временную таблицу и соответствующим образом перепишите update. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2020, 10:46 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
Для таких алгоритмов надо где-то хранить эти промежуточные данные и считать каждый месяц, например Рассчитывать их каждый раз - моветон ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2020, 10:48 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
andreymx Для таких алгоритмов надо где-то хранить эти промежуточные данные и считать каждый месяц, например Рассчитывать их каждый раз - моветон Я это все прекрасно понимаю. Но вот данные меняют задним числом (приходят корректировки и тп). Это в 1С есть понятие закрытий период. В данной системе такого нет. Пересчет за 2 месяца выполняется 1 раз в месяц - не так критично. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2020, 10:59 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
Oleg_SQL, а как вы бухгалтерскую отчетность поддерживаете? Я понимаю, что так поступали в 90х, но сейчас без закрытия периода никак нельзя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2020, 11:25 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
Владислав Колосов Oleg_SQL, а как вы бухгалтерскую отчетность поддерживаете? Я понимаю, что так поступали в 90х, но сейчас без закрытия периода никак нельзя. Это данные не для строгой отчетности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2020, 11:49 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
Олег А сам расчёт работает корректно, Но медленно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2020, 12:17 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
andreymx Олег А сам расчёт работает корректно, Но медленно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2020, 12:17 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
andreymx andreymx Олег А сам расчёт работает корректно, Но медленно? Работает корректно. Но медленно. Все верно. Запрос написан не мной. И по принципу работает - не трогай я хотел оптимизировать его не внося корректировку в код. Не особо погружаясь в логику. Видимо придется погрузиться и внести кардинальные изменения (чувствую, что это возможно). P.S. Кластерный индекс строится уже более часа... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2020, 12:35 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
Oleg_SQL alexeyvg, Алгоритм расчета такой,что однозначно нужно считать каждую неделю с учетом предыдущих данных. Вы говорите "нужно считать каждую неделю с учетом предыдущих данных", а в запросе вы делаете другое - считаете все следующие записи по текущей записи, потом считаете все следующие записи по следующей записи, и т.д. Это очень сильно отличается. "нужно считать каждую неделю с учетом предыдущих данных" в какой то степени похоже на "накопительный итог", это можно считать, не апдэйтя данные за всё время столько раз, сколько строк в таблице ,а за один проход. И, конечно, не апдэйтя таблицу, а вставляя в новую. Тогда у вас общее время пересчёта по сути будет равно одному скану таблицы (правда, будут затраты памяти, для хранения накопительных счётчиков, по числу сочетаний StoreID и GoodID) То есть в тыщи раз быстрее, чем сейчас. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2020, 15:23 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
alexeyvg, alexeyvg, Запрос: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. В идеале вместо WHERE [snp].[dt] BETWEEN @dtnext AND @curperiodend нужно WHERE [snp].[dt] =@dtnext Т.е. брать данные одной недели и апдейтить их данными предыдущей. Но на предыдущей неделе может не быть данных по товару - они были 5/6/12... недель назад. Поэтому делается апдейт всего что после текущей (@dt), а как дойдет до недели где опять есть этот товар, то по нему проапдейтится сново все далее... Одним запросом это сделать - не могу сообразить как. Ведь данные по каждой неделе постоянно меняются и 10 неделя до начала расчета будет не той как после 2, 3 и тп шагов... По идее вот я получил данные по товару Х за 1 неделю и мне нужно не все со 2-й по 50-ю неделю обновлять, а только первую неделю где есть этот товар. Лишь в этом я вижу возможность уменьшить число строк для обновления. Т.е. нечто типа OUTER APPLY (SELECT TOP 1 ... ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2020, 15:54 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
Сделал так, чтобы наоборот для выбранной недели находились прошлые данные Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. Стало медленнее раза в 3. В добавок, OUTER APPLY при больших объемах у нас уже вызывал полное зависание (проц = 0%, диск = 0% и тп) при этом ошибок не давал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2020, 16:46 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
автор OUTER APPLY (SELECT TOP 1 ...) да по куче, да с таким количеством предикатов... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2020, 17:54 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
Oleg_SQL, OUTER APPLY ... order by откуда там взяться производительности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2020, 18:35 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
Oleg_SQL Одним запросом это сделать - не могу сообразить как. LAG (Price) OVER ( [ partition by StoreID, GoodID order by dt) вернёт вам значение Price для тех же StoreID и GoodID за предыдущий день ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2020, 18:53 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
Oleg_SQL Стало медленнее раза в 3. В добавок, OUTER APPLY при больших объемах у нас уже вызывал полное зависание (проц = 0%, диск = 0% и тп) при этом ошибок не давал. Без индекса это неприемлемо (как и вариант с LAG) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2020, 19:04 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
Oleg_SQL затраты по времени на построение индекса иногда съедают всю выгоду от них (не менее часа, думаю будет длится) Не для расчёта, а вообще, и не надо их строить-удалять ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2020, 19:06 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
alexeyvg Oleg_SQL Стало медленнее раза в 3. В добавок, OUTER APPLY при больших объемах у нас уже вызывал полное зависание (проц = 0%, диск = 0% и тп) при этом ошибок не давал. Без индекса это неприемлемо (как и вариант с LAG) Я конечно не профессор, но кластерный индекс был построен по всем указанным полям. В данный момент я добавил при вставке во временную таблицу поле rn (row_number) и добавил его в кластерный индекс. Теперь добавил условие в INNER JOIN : AND snp.RN = snpPrev.RN + 1 Обработка взлетела )) Вот только много времени уходит на саму вставку в #salesPromo со всеми индексами и row_number(OVER(PARTITION BY... ORDER BY...). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2020, 09:13 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
alexeyvg Oleg_SQL Одним запросом это сделать - не могу сообразить как. LAG (Price) OVER ( [ partition by StoreID, GoodID order by dt) вернёт вам значение Price для тех же StoreID и GoodID за предыдущий день Код: sql 1. 2. 3. 4. dt val lastvalue ----------- ----------- ----------- 20200101 100 NULL 20200108 NULL 100 20200115 NULL NULL 20200122 120 NULL а мне нужно для 20200122 значение lastvalue = 100. Последнее не пустое значение , а не значение прошлой строки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2020, 11:26 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
alexeyvg Oleg_SQL затраты по времени на построение индекса иногда съедают всю выгоду от них (не менее часа, думаю будет длится) Не для расчёта, а вообще, и не надо их строить-удалять я же в расчете использую временную таблицу... как им там быть то? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2020, 11:31 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
Oleg_SQL, вы индекс строите после заполнения таблицы или до? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2020, 12:36 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
felix_ff Oleg_SQL, вы индекс строите после заполнения таблицы или до? Конечно же ДО ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2020, 13:39 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
Oleg_SQL, В таком случае что там у вас с планом запроса наполнения временной таблицы? есть ли оператор сортировки? Для такого некислого объема вставка по определению может быть не особо быстрой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2020, 13:47 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
felix_ff Oleg_SQL, В таком случае что там у вас с планом запроса наполнения временной таблицы? есть ли оператор сортировки? Для такого некислого объема вставка по определению может быть не особо быстрой. Со вставкой уже ничего не поделаешь - манипулировать с рабочей таблицей (индексы и тп) мне не дают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2020, 14:17 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
Oleg_SQL а мне нужно для 20200122 значение lastvalue = 100. Последнее не пустое значение , а не значение прошлой строки. Код: sql 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2020, 15:09 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
Oleg_SQL alexeyvg пропущено... Индексы должны быть в базе. Не для расчёта, а вообще, и не надо их строить-удалять я же в расчете использую временную таблицу... как им там быть то? Другое дело, что схема исходных таблиц сложнее, и по ней не получится так легко сделать интересующий сложный запрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2020, 15:12 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
Oleg_SQL, Вообще есть смысл строить все индексы уже после наполнения временной таблицы. Сначала кластерный, потом некластерные, если есть. Если вы построите индекс по существующим данным, вместе с индексом построится актуальная статистика. А если наоборот - останется только надеяться на автопересчет статистик. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2020, 15:28 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
[quot alexeyvg#22246312] Oleg_SQL а мне нужно для 20200122 значение lastvalue = 100. Последнее не пустое значение , а не значение прошлой строки. Да, всё верно. Я уже заметил и поправил. На скорость это не повлияло. Но это был тестовый запрос для успокоения души )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2020, 15:33 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
0wl Oleg_SQL, Вообще есть смысл строить все индексы уже после наполнения временной таблицы. Сначала кластерный, потом некластерные, если есть. Если вы построите индекс по существующим данным, вместе с индексом построится актуальная статистика. А если наоборот - останется только надеяться на автопересчет статистик. Записать 500 млн записей, а потом начать строить кластерный индекс? Это будет реально быстрее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2020, 15:39 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
Oleg_SQL Записать 500 млн записей, а потом начать строить кластерный индекс? Это будет реально быстрее? Я бы и рад сказать «да, я был прав» или «нет, я ошибся», но тут возможны варианты. Если сначала залить данные в кучу, а потом построить по ним индекс, они запишутся 2 раза. И нужно будет выделить место в файле данных для создания индекса. Зато можно использовать BULK INSERT (ну или SELECT … INTO) и ускорить первоначальную вставку в кучу. (см. https://docs.microsoft.com/en-US/sql/relational-databases/import-export/prerequisites-for-minimal-logging-in-bulk-import?view=sql-server-ver15#table-requirements-for-minimally-logging-bulk-import-operations) С другой стороны, если данные заливаются в кластерный индекс пачками, в несколько транзакций, то в процессе заливки несколько раз сработает автоапдейт статистик. Но это чтения, а не запись, к тому же, чтения какого-то сэмпла, а не всей таблицы. В общем, я бы замерил варианты. Ну и если выбирать второй вариант, то по окончании заливки пересчитал бы статистику с FULLSCAN, чтобы гарантировать, что план будет эффективным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2020, 17:50 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
0wl Зато можно использовать BULK INSERT (ну или SELECT … INTO) и ускорить первоначальную вставку в кучу. Но надо одной операцией, а не "пачками". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2020, 19:17 |
|
||
|
Большой UPDATE
|
|||
|---|---|---|---|
|
#18+
Oleg_SQL Да, всё верно. Я уже заметил и поправил. На скорость это не повлияло. Но это был тестовый запрос для успокоения души )) Oleg_SQL В идеале вместо WHERE [snp].[dt] BETWEEN @dtnext AND @curperiodend нужно WHERE [snp].[dt] =@dtnext Т.е. брать данные одной недели и апдейтить их данными предыдущей. Но на предыдущей неделе может не быть данных по товару - они были 5/6/12... недель назад. Поэтому делается апдейт всего что после текущей (@dt), а как дойдет до недели где опять есть этот товар, то по нему проапдейтится сново все далее... Как я понял, у вас отсутствие данных означает не наличие записи во значением поля Price, равным NULL, а именно отсутствие записи. Если "отсутствие данных" означает "отсутствие записи", то цикл апдэйтов заменяется на рекурсивный CTE по датам, с заменой OUTER APPLY на LAG, и на итоговую вставку в таблицу результата, соответственно, с возможностью использовать индексы постоянных таблиц Тогда всё будет кардинально быстрее. Ну или вообще нужно менять модель данных, на что выше намекали, но на это вы вряд ли пойдёте, это уже не "оптимизация", а "перепроектирование системы". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2020, 19:28 |
|
||
|
|

start [/forum/topic.php?all=1&fid=46&tid=1685305]: |
0ms |
get settings: |
10ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
24ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
89ms |
get tp. blocked users: |
1ms |
| others: | 251ms |
| total: | 399ms |

| 0 / 0 |
