Оптимизация запроса

Форум Программирование Общие вопросы программирования (Dev)

1. Cool_vsi 05.02.19 08:47 Сейчас в теме

для ут 10.3 помогите оптимизировать запрос -

ВЫБРАТЬ РАЗЛИЧНЫЕ
	ВЫРАЗИТЬ(ЗаказыПокупателейОстатки.ЗаказПокупателя КАК Документ.ЗаказПокупателя) КАК ЗаказПокупателя
ИЗ
	РегистрНакопления.ЗаказыПокупателей.Остатки(, ЗаказПокупателя В (&МассивДокументов)) КАК ЗаказыПокупателейОстатки
ГДЕ
	ЗаказыПокупателейОстатки.КоличествоОстаток <> 0

я так понимаю таблица остатки виртуальная, по идее если уйти от виртуальной таблице должно быстрее работать.

По теме из базы знаний

Найденные решения

15. dhurricane 05.02.19 09:13 Сейчас в теме

(8) Ну так это важное условие, зря Вы его опустили в исходном сообщении. :)

Проверьте, индексируется ли у Вас измерение "ЗаказПокупателя", либо стоит ли оно первым среди измерений регистра? Если так, не представляю, чем еще можно помочь. Разве что убрать ключевое слово "РАЗЛИЧНЫЕ", оно здесь бессмыслено. Ну и проверить актуальность итогов в базе.

Может стоит рассмотреть модификацию запроса списка, путем добавления левого соединения основной таблицы с таблице остатков?

Остальные ответы

Подписаться на ответы Инфостарт бот

Свернуть все

5. dhurricane 05.02.19 08:59 Сейчас в теме

(1) А что не так? Вполне корректный запрос, если Вы действительно пытаетесь получить только те заказы, по которым есть остаток. Из исходной таблицы Вы остаток не получите, только если станете рассчитывать его сами. Но этот способ очевидно более ресурсозатратный, т.к. при поддержке итогов ИБ в актуальном состоянии, данные для представленной виртуальной таблицы уже есть в базе, хранятся в отдельной таблице и их не нужно рассчитывать.

8. Cool_vsi 05.02.19 09:03 Сейчас в теме

(5) он выполняется для списка при событие При получение данных, из-за этого список медленно листается, в замере производительности 90 процентов тратиться на этот запрос.

15. dhurricane 05.02.19 09:13 Сейчас в теме

16. Cool_vsi 05.02.19 09:15 Сейчас в теме

(15) там не управляемая форма, и список формируется не запросом.
Что я не указал в исходном сообщение? я вас не понимаю

Измерение не индексировалось и стояло 2 в списке(порядок в списке на что то влияет? )
Сейчас поставил индексацию и первым, по результату отпишусь

17. dandykry 10 05.02.19 09:17 Сейчас в теме

(16) Измерения регистра сами индексируются.

Скажи лучше время выполнения 1 запроса и количество запросов, которое было сделано в измеряемый промежуток времени.

У меня ощущение, что запрос не виноват

19. Cool_vsi 05.02.19 09:18 Сейчас в теме

(17)

чше время выполнения 1 запроса и количество запросов, которое было сделано в измеряемый промежуток времени.

У меня ощущение, что запрос не виноват

вот замер производительности по нем

Прикрепленные файлы:

25. dandykry 10 05.02.19 09:32 Сейчас в теме

(19) Попрогбуй так

ВЫБРАТЬ
	Заказ.Ссылка КАК ЗаказПокупателя
ПОМЕСТИТЬ ВТ_ЗаказыПокупателя
ИЗ
	Документ.ЗаказПокупателя КАК Заказ
ГДЕ
	Заказ.Ссылка В(&МассивДокументов)

ИНДЕКСИРОВАТЬ ПО
	ЗаказПокупателя

;
ВЫБРАТЬ 
    ЗаказыПокупателейОстатки.ЗаказПокупателя  КАК ЗаказПокупателя
ИЗ
    РегистрНакопления.ЗаказыПокупателей.Остатки(, ЗаказПокупателя В (ВЫБРАТЬ ВТ_ЗаказыПокупателя.ЗаказПокупателя ИЗ ВТ_ЗаказыПокупателя КАК ВТ_ЗаказыПокупателя)) КАК ЗаказыПокупателейОстатки
ГДЕ
    ЗаказыПокупателейОстатки.КоличествоОстаток <> 0

Показать

23. dhurricane 05.02.19 09:26 Сейчас в теме

(17) Индексируются, но по умолчанию в том порядке, как они заданы в конфигураторе. Коли заказ оказался на втором месте, индекс может не использоваться, т.к. пропущено условие по первому измерению. Здесь либо изменить порядок, либо проиндексировать заказ. Оба действия делать не обязательно.

18. starjevschik 05.02.19 09:18 Сейчас в теме

(8) вечная проблема. С запросом ничего не сделаешь. Оптимизировать это все можно пытаться какими-то другими путями, но они все будут неидеальны. Например в заказе сделать реквизит - конечный остаток по заказу и тщательно заполнять его при всех движениях. И по нему делать отбор. А допустим по ночам проверять его запросом остатков по регистру один раз в сутки.
Или объяснить пользователям, что увы.
База файловая? Сиквел нужен с хорошим сервером для таких списков.

20. Cool_vsi 05.02.19 09:19 Сейчас в теме

(18) база sql, два отдельных сервера 1с и sql, причем сервер 1с загружен очень слабо. на сервере sql также ресурсов памяти и процессора достаточно

21. starjevschik 05.02.19 09:21 Сейчас в теме

(20) еще вариант сделать сразу список заказов с ненулевым остатком. При открытии формы такой запрос по всем заказам и в список только заказы с остатками. Тогда он открываться будет подольше, но список будет работать как обычный список, быстро.
При листании списка такие запросы это дохлый номер.

22. Cool_vsi 05.02.19 09:23 Сейчас в теме

(21) некоторые с утра зашли в базу и до вечера не выходят, получиться что весь день в списке будут не актуальные данные =(

а если сделать я вот думаю константу глобальную. и регламентным заданием раз в пару минут ее обновлять, также быстрее будет?

24. Cool_vsi 05.02.19 09:28 Сейчас в теме

(22)
(16)вообщем стало гораздо быстрее работать, после того как в регистре поставил для измерения Заказ индексацию, и первым в списке его

10. dandykry 10 05.02.19 09:04 Сейчас в теме

(1)

ЗаказПокупателя В (&МассивДокументов)

Это делать не рекомендуется. особенно если в массиве много документов.
Лучше получить их в временной таблице, проиндексировать и внутренним соединением фильтровать или

ЗаказПокупателя В (ВЫБРАТЬ ВТ.Заказ ИЗ ВТМассивДокументов КАК ВТ)

35. buganov 200 05.02.19 10:21 Сейчас в теме

(10) зачем поднимать данные во временную таблицу? Что за бред?

2. Swetlana 25 05.02.19 08:51 Сейчас в теме

Для виртуальной таблицы необходимо все условия заносить в условия виртуальной таблицы а не в условие ГДЕ
т.е. там же где находится условие ЗаказПокупателя В (&МассивДокументов)

3. dhurricane 05.02.19 08:56 Сейчас в теме

(2) Извините, но это глупость. Там возможны только условия по измерениям. Вы не сможете добавить условия по полям остатка в параметры виртуальной таблицы.

6. Swetlana 25 05.02.19 08:59 Сейчас в теме

(3) кстати да, забыла, подзабыла запросы

4. kumi2012 103 05.02.19 08:58 Сейчас в теме

Лучше оптимизировать получение &МассивДокументов.

7. Cool_vsi 05.02.19 09:01 Сейчас в теме

(4)как ? запрос выполняется для списка документов, массив получаю 1 раз-

МассивДокументов = Новый Массив;
	Для каждого ОформлениеСтроки Из ОформленияСтрок Цикл
		МассивДокументов.Добавить(ОформлениеСтроки.ДанныеСтроки.Ссылка);
	КонецЦикла;

9. kumi2012 103 05.02.19 09:04 Сейчас в теме

(7) Вопрос оптимизации возник из-за большого размера МассивДокументов?
Запрос к регистру накопления у Вас корректный.

11. Cool_vsi 05.02.19 09:06 Сейчас в теме

(9) это выполняеться для списка, список медленно листается ,в массиве всего около 40 документов.

12. dandykry 10 05.02.19 09:08 Сейчас в теме

(11) А запрос ДС покажи на всякий)) и скажи в замере сколько раз этот запрос выполнился?

13. Cool_vsi 05.02.19 09:10 Сейчас в теме

(12)

ДС покажи на всякий)) и скажи в заме

какой ДС?
вот он в замере производительности

Прикрепленные файлы:

14. dandykry 10 05.02.19 09:12 Сейчас в теме

(13) ДС - динамический список. (конечно же неуместный вопрос для неуправляемых форм. Каюсь)

1755 раз. А время выполнения 1 запроса?

26. Cool_vsi 05.02.19 09:38 Сейчас в теме

Вообщем всем спасибо, запрос остался тот же, индексация измерения в регистре Заказ покупателя, очень сильно помогла, список стал листатся очень быстро! Всем спасибо, не знал что индексация так влияет.

27. VoShk 22 05.02.19 09:41 Сейчас в теме

Как вариант:

ВЫБРАТЬ 
    ВЫРАЗИТЬ(ЗаказыПокупателейОстатки.ЗаказПокупателя КАК Документ.ЗаказПокупателя) КАК ЗаказПокупателя
ИЗ
    РегистрНакопления.ЗаказыПокупателей.Остатки КАК ЗаказыПокупателейОстатки
ВНУТРЕННЕЕ СОЕДИНЕНИЕ 
   Документ.ЗаказПокупателя КАК ЗаказыПокупателейДокументы ПО ЗаказыПокупателейДокументы .Ссылка В (&МассивДокументов)
И ЗаказыПокупателейОстатки.ЗаказПокупателя = ЗаказыПокупателейДокументы.Ссылка
ГДЕ
    НЕ ЗаказыПокупателейОстатки.КоличествоОстаток = 0
СГРУППИРОВАТЬ ПО ЗаказПокупателя

Показать

28. dhurricane 05.02.19 09:46 Сейчас в теме

(27) В этом случае сначала будет получена виртуальная таблица остатков по всем заказам, а потом уже будет отфильтрована по нужным. Вряд ли это может быть оптимальнее, чем фильтровать таблицу итогов до получения остатков. Ну и группировка здесь совершенно лишняя.

29. VoShk 22 05.02.19 09:55 Сейчас в теме

(28) Нет, там будет произведено связывание таблиц с index scan в худшем случае, что чаше быстрей создания отдельной таблицы.

По поводу индексирования: индексирование тратит слишком много времени и обычно неэффективно в случае однократного использования таблицы далее (там создаётся кластерный индекс, что, по сути, равно созданию второй таблицы)

30. dhurricane 05.02.19 10:03 Сейчас в теме

(29)

По поводу индексирования

Речь об индексировании измерения регистра?

32. VoShk 22 05.02.19 10:05 Сейчас в теме

(30) индексирование вот это:

ВЫБРАТЬ 
Заказ.Ссылка КАК ЗаказПокупателя 
ПОМЕСТИТЬ ВТ_ЗаказыПокупателя 
<skipped>
ИНДЕКСИРОВАТЬ ПО 
ЗаказПокупателя

Что физически происходит - создаётся новая таблица, потом она целиком сканируется для создания индекса и создаётся кластерный индекс, который содержит все колонки таблицы, т.е. создаётся ещё одна такая же таблица

33. dhurricane 05.02.19 10:07 Сейчас в теме

(32) А, ну это не мое предложение. :) И согласен с Вами.

31. dhurricane 05.02.19 10:05 Сейчас в теме

(29)

связывание таблиц с index scan

Спасибо, возьму на заметку.

36. buganov 200 05.02.19 10:23 Сейчас в теме

(27)

ГДЕ
НЕ ЗаказыПокупателейОстатки.КоличествоОстаток = 0

лишнее

37. dhurricane 05.02.19 10:40 Сейчас в теме

(36) Нет, если есть и другие ресурсы регистра

40. buganov 200 05.02.19 11:44 Сейчас в теме

(37)Да, согласен. Не учел, что ресурсов несколько и они могут списываться неровно. Сумма по идее должна списываться вместе с количеством.

38. dandykry 10 05.02.19 10:44 Сейчас в теме

(36) Что за бред - думаешь только 1 ресурс может быть в таблице? По количеству 0, а по сумме или еще какому-то ресурсу не 0
(35) Потому что читать ИТС нужно и не называть бредом. А почитать нужно "практическое пособие разработчика" хотя бы. Там написаны рекомендации - "как работать с виртуальными таблицами, ограничения на соединения с виртуальными таблицами и очень много всего, что видимо ты считаешь бредом)))

39. buganov 200 05.02.19 11:35 Сейчас в теме

(38) ты сам то пробовал на практике это? Прежде, чем тыкать в книжки, попробуй на больших данных свои тыки. И рекомендации это рекомендации, на практике все может оказаться совсем иначе. И поднимать гигабайты данных, чтобы поперекладывать их по временным таблицам неведомая роскошь.
П.С. иди и почитай ИТС, а потом на больших данных опробуй различные варианты и удивись.
П.С.С. Секс в теории и на практике сильно отличаются

41. dandykry 10 05.02.19 12:06 Сейчас в теме

(39) Хорошо. Объясняю теорию

Таблица остатков.
заказ1 15 20
заказ1 11 30
заказ2 15 20
заказ2 15 20
.....................
заказN 15 20

Чтобы всю ее не фильтровать мы используем отбор по измерению заказ (это как раз когда в параметрах виртуальной таблицы указываем Заказ = &МойЗаказ

Измерения регистров индексируются, поэтому этот отбор работает быстро.

Теперь представляем, что у нас не Заказ = &МойЗаказ а Заказ В (&МассивМоихЗаказов)

теперь чтобы системе установить отбор нужно виртуальную таблицу обработать (находить нужное умеет только по индексу или перебором. Как придумали в бородатых годах со времен баз данных так ничего нового и не придумали. Перебираем строки или ищем по индексу)

Так вот когда Заказ В (&МассивМоихЗаказов) тогда 90% это перебор т.к. хер знает что такое этот массив и он точно не проиндексирован. Т.е для каждой записи виртуальной таблицы он будет перебирать массив, чтобы выяснить ИзмерениеЗаказ = ЭлементМассива.

Когда заранее готовишь отдельную временную таблицу с отбором и индексируешь ее, то перебора может не возникнуть, а будет поиск по индексу (космос, супер, фантастика)

Еще нужно помнить, что реальный запрос к sql к виртуальной таблице не сводится к sel ect Fielt Fr om VirtyalnayaTablichka_name а имеет собственные левые соединения (план запросика надо посмотреть)

И реально на больших данных такие конструкции выигрывают в скорости (а иногда и в стабильности потому что планы запросов берут и меняются по воли sql), нооооооооооооооооооооооооо
Книжки это херня я уже понял. Нахер теорию и опыт умных дядек. Херню городят и 1ски разрабатывают

42. buganov 200 05.02.19 12:21 Сейчас в теме

(41) мда. реальный запрос к sql к виртуальной таблице не сводится к sel ect Fielt Fr om VirtyalnayaTablichka_name
Что правда что ли?

SEL ECT
T1.Fld4743RRef,
T1.Fld4744RRef,
T1.Fld4745RRef,
T1.Fld7607_,
T1.Fld4746Balance_,
T1.Fld4747Balance_
FR OM (SELECT
T2._Fld4744RRef AS Fld4744RRef,
T2._Fld4743RRef AS Fld4743RRef,
T2._Fld4745RRef AS Fld4745RRef,
T2._Fld7607 AS Fld7607_,
T2._Fld4746 AS Fld4746Balance_,
T2._Fld4747 AS Fld4747Balance_
FR OM _AccumRgT4748 T2 WITH(NOLOCK)
WH ERE T2._Period = @P1 AND (T2._Fld4746 <> @P2 OR T2._Fld4747 <> @P3)) T1

Показать

ВЫБРАТЬ
ЗаказыНаПеремещениеОстатки.ЗаказНаПеремещение,
ЗаказыНаПеремещениеОстатки.Номенклатура,
ЗаказыНаПеремещениеОстатки.Характеристика,
ЗаказыНаПеремещениеОстатки.КодСтроки,
ЗаказыНаПеремещениеОстатки.ЗаказаноОстаток,
ЗаказыНаПеремещениеОстатки.КОформлениюОстаток
ИЗ
РегистрНакопления.ЗаказыНаПеремещение.Остатки КАК ЗаказыНаПеремещениеОстатки

Таблица(не виртуальная) регистра _AccumRg4742

Покажи мне, дураку, где тут не sel ect Fielt Fr om VirtyalnayaTablichka_name а имеет собственные левые соединения (план запросика надо посмотреть).
Я посмотрел.

43. dhurricane 05.02.19 12:28 Сейчас в теме

(41) Прошу прощения, что встреваю. Но почему Вы пренебрегаете поиском записей в таблице заказов, если по Вашим же словам там с вероятностью в 90% будет перебор? А также пренебрегаете временем создания новой виртуальной таблицы. И если же она создаваться не будет, а SQL превратит все это в собственные левые соединение, то зачем тогда индексировать по полю "Ссылка"?

44. dandykry 10 05.02.19 12:40 Сейчас в теме

(43) Я думаю, что отдельно найти нужные ссылки в временной таблице быстрее (перебора вроде не должно быть, ссылка индексируется). Да это затраты, но я имел ввиду случаи, когда документов реально много. И всего лишь попросил попробовать, а не говорил, что это истинное решение. Вот только с ходу бредом назвали, даже не аргументируя.

45. buganov 200 05.02.19 12:53 Сейчас в теме

(44) бредом я назвал бездумное использование временной таблицы.
Аргументирую, чем плохо использование ВТ.
1. Затраты на ее создание и построение индекса
2. Оптимизатор запроса SQL совсем ничего не значет, что у него хранится в ВТ, это отдельный запрос.
3. При построении огромной таблицы выталкивается кеш, что негативно влияет на производительность.
4. Для чего создавать целую таблицу для единичной выборки данных.
Попробовал выбрать через В(&Массив). Index seek Это ни разу не перебор.
Опять же, часто использование временной таблицы обосновано задачей и данными.

46. dandykry 10 05.02.19 13:08 Сейчас в теме

(45) Аргументы приняты)
хорошо, в этом случае отдельно в ВТ это не лучшая идея. (проверил 40 -100 заказов что так что так одинаково +- дестятысячные)
Все же думаю если заказов больше, такая конструкция имеет место быть

47. buganov 200 05.02.19 13:18 Сейчас в теме

(46) в любом случае, лучше взять таблицу шапок заказов, нежели взять их, положить в контейнер, и только потом связывать.

48. dandykry 10 05.02.19 13:39 Сейчас в теме

(47)
Возможно, но я тут уже по принципу

34. Cool_vsi 05.02.19 10:18 Сейчас в теме

без индексирования в регистре на 8 раз выполнения запроса тратилось 2.7 секунды, сейчас на 8 раз выполнения запроса тратиться 0.18 сек, то есть стало отлично. Менять запрос уже нет смысла?

49. 1qazxsw21QAZXSW2 4 06.02.19 21:42 Сейчас в теме

Позвновательные ответы

Оставьте свое сообщение

E-mail: