Разыменования в коде (и прочее) - что при этом делает СУБД

Публикация № 1003601

Администрирование - Производительность и оптимизация (HighLoad)

MSSQL Profiler разыменование SELECT

77
Смотрим Profiler, делаем выводы.

Уже как несколько месяцев занимаемся укрупнением одной из наших информационных систем - переводим пользователей периферийных баз РБД на работу в общей базе данных. Такого вида деятельность предполагает дополнительные доработки для повышения масштабируемости ИС. Один и способов таких доработок - анализ тяжелых запросов. Собственно, вот, периодически занимаюсь таким анализом.

И вот "ради интереса" стали возникать вопросы - что же делает платформа на СУБД при выполнении каких-то операций. Вероятно, часть приведенных ниже результатов для кого-то будет далеко не новость (как и для меня). Но уж, простите, стараюсь раскопать тему насколько можно глубже и, главное, увидеть происходящее собственными глазами.

Тесты будем производить на демо-базе БСП 2.4 (версия 2.4.6.241), на платформе 1С:Предприятие 8.3 (8.3.10.2580), с использованием толстого обычного и тонкого клиентов, без RLS. Для возможности запуска тестовой обработки в обычном толстом клиенте, для конфигурации переключим Основной режим запуска - Обычное приложение. В тестовой внешней обработке добавим обычную форму, на ней разместим поле ввода с типом ДокументСсылка._ДемоЗаказПокупателя. Для тестирования будем добавлять кнопки с короткими обработчиками.

Вооружимся SQL Server Profiler. И поехали...

 

Классическое разыменование

Добавим кнопку с коротким обработчиком:

	Валюта = ЗаказСсылка.Валюта;
	Сообщить(Валюта.Наименование);

Выполнение второй строки (Сообщить(...)) вызывает полное вычитывание полей элемента.

 
 Запрос

Ничего необычного, все ожидаемо. 

 

Представление элемента

	Валюта = ЗаказСсылка.Валюта;
	Сообщить(Строка(Валюта));

Уже интереснее. Выполнение второй строки (Сообщить(...)) вызывает вычитывание только Ссылки и Наименования элемента справочника.

 
 Запрос

 

Классическое разыменование сложного объекта

Под сложными имею в виду объекты, имеющие табличные части. Как раз, документ _ДемоЗаказПокупателя нам вполне подходит.

Разыменовываем номер документа:

Сообщить(Строка(ЗаказСсылка.Номер));

Получаем полное вычитывание документа - и реквизитов, и ТЧ (т.е., несколько запросов).

 
 Запросы

Хех, а хотелось бы - не обращаться к данным ТЧ без надобности. Читал, конечно, что платформа так не умеет. Но надежда теплилась - вдруг я чего-то пропустил, и в платформе появилось "чтение по требованию".

При разыменовании строки ТЧ, уже ожидаемо, вычитывается весь объект. Код:

Сообщить(ЗаказСсылка.СчетаНаОплату[0].Вид);

 

Представление сложного элемента

Выполним:

Сообщить(Строка(ЗаказСсылка));

Платформа генерит запрос на чтение Ссылки, Даты и Номера документа, без выборок ТЧ. Это уже ожидаемо. В условие выборки, кстати, еще докидывается отбор по разделителю области данных (T1._Fld2683 = @P1).

 
 Запрос

 

Несколько вычитываний

Тут сюрпризов нет. Вычитывания вида (ниже) к повторам чтения на СУБД - не ведут.

	Сообщить("" + Валюта + Валюта);
	Сообщить("" + ЗаказСсылка.Номер + ЗаказСсылка.Договор);

Разве что, добавляются запросы для получения представлений ссылочных реквизитов (Договор, в нашем случае).

 

Выполнение инициализации объекта при разыменованиях

Закрались подозрения, что полное вычитывание является синонимом Ссылка.ПолучитьОбъект(). Однако, нет. Код инициализации объекта при разыменованиях НЕ выполняется.

"Зато" при полном вычитывании (в отличие от Ссылка.ПолучитьОбъект()) выполняется предварительный запрос получения последней версии объекта и полученное значение дополнительно участвует в отборе.

 
 Запросы при разыменовании

 

Открытие управляемой формы

В тестовой обработке создадим дополнительную управляемую форму с основным реквизитом ДокументОбъект._ДемоЗаказПокупателя. И посмотрим, что будет происходить при открытии управляемой формы документа.

А происходит вот что.

  • Полное вычитывание всех реквизитов документа и его ТЧ. Ну это ожидаемо.
  • Для всех ссылочных реквизитов самого документа (не ТЧ) выполняется несколько коротких запросов для получения представлений ссылок. В принципе, тоже ожидаемо. 
  • Для ссылочных реквизитов ТЧ выполняются запросы вида: 
    SELECT
    T1._IDRRef,
    T1._Description
    FROM dbo._Reference33 T1
    WHERE ((T1._Fld2683 = @P1)) AND ((T1._IDRRef IN (@P2, @P3)))
    ORDER BY T1._IDRRef

    где @P2, @P3 - перечисление ссылок какого-то ссылочного поля ТЧ, без дублей. Причем, для ТЧ проверка IN (@...) конструируется и для случаев, когда нужно получить представление только для одной ссылки (т.е., без замены на "=").

 

Открытие обычной формы объекта с ТЧ

Мда, это ахтунг и источник массы запросов с получением представлений.

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

Сделали выводы, переделываем... В формах, где может быть потенциально много строк ТЧ, скрыли стандартные ссылочные поля. Их представления получаем разом и помещаем в соответствие. Полученные текстовки выводим в специально добавленные колонки ТЧ.

 

Журналы документов

Вывод списка журнала документов и послужил началом для моих экспериментов. А все потому что в топе запросов, нагружающих процессор, был запрос вида:

SELECT 
[Список полей]
FROM dbo._DocumentJournal836 T1
LEFT OUTER JOIN dbo._Reference16 T2
ON (T1._Fld838RRef = T2._IDRRef) AND (T2._Fld2683 = @P1)
LEFT OUTER JOIN dbo._Reference33 T3
ON (T1._Fld840RRef = T3._IDRRef) AND (T3._Fld2683 = @P2)
LEFT OUTER JOIN dbo._Reference16 T4
ON (T1._Fld839RRef = T4._IDRRef) AND (T4._Fld2683 = @P3)
LEFT OUTER JOIN dbo._Reference19 T5
ON (T1._Fld837RRef = T5._IDRRef) AND (T5._Fld2683 = @P4)
LEFT OUTER JOIN dbo._Document581 T6
ON (T1._DocumentTRef = 0x00000245 AND T1._DocumentRRef = T6._IDRRef) AND (T6._Fld2683 = @P5)
LEFT OUTER JOIN dbo._Document579 T7
ON (T1._DocumentTRef = 0x00000243 AND T1._DocumentRRef = T7._IDRRef) AND (T7._Fld2683 = @P6)
LEFT OUTER JOIN dbo._Document578 T8
ON (T1._DocumentTRef = 0x00000242 AND T1._DocumentRRef = T8._IDRRef) AND (T8._Fld2683 = @P7)
WHERE ((T1._Fld2683 = @P8)) AND (((T6._Fld803RRef = @P9 OR T7._Fld679RRef = @P10 OR T8._Fld667RRef = @P11)))
ORDER BY T1._Date_Time, T1._DocumentTRef, T1._DocumentRRef
 
 Полный запрос

Сразу обозначу, что это происходило для списка журнала документов в обычном приложении и обычной (неуправляемой) форме. В этой форме, при открытии, сразу накладывался отбор по полю журнала.

Т.е., помимо ожидаемых соединений со справочниками для представлений ссылок, в запросе еще присутствуют соединения с документами журнала. А еще какое "красивое" условие в секции WHERE/ГДЕ...

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

После разных предположений и экспериментов выяснено, что такая конструкция добавляется платформой при наличии соответствующих критериев отбора. Все места использования списков журнала документов в обычных формах переделали на получение данных запросом или реализовали новые управляемые формы.

 

Выборка данных

Посмотрим, что происходит на СУБД при выполнении метода МенеджерОбъекта.Выбрать(...). Для примера будем использовать справочник КлючевыеОперации.

А происходит следующее. Данные вычитываются частями с использованием TOP 25.

 
 Запросы

 

ПРЕДСТАВЛЕНИЕ и ПРЕДСТАВЛЕНИЕССЫЛКИ (из языка запросов)

Посмотрим, как использование функций ПРЕДСТАВЛЕНИЕ и ПРЕДСТАВЛЕНИЕССЫЛКИ языка запросов выражается в конечном запросе СУБД. Используем такой вот запрос:

ВЫБРАТЬ
	Пользователи.Ссылка КАК Ссылка,
	Пользователи.Наименование КАК Наименование,
	Пользователи.Недействителен КАК Недействителен,
	"ПРЕДСТАВЛЕНИЕ(Пользователи.Ссылка)" КАК Поле1,
	ПРЕДСТАВЛЕНИЕ(Пользователи.Ссылка) КАК СсылкаПредставление,
	"ПРЕДСТАВЛЕНИЕ(Пользователи.Комментарий)" КАК Поле2,
	ПРЕДСТАВЛЕНИЕ(Пользователи.Комментарий) КАК КомментарийПредставление1,
	"ПРЕДСТАВЛЕНИЕССЫЛКИ(Пользователи.ФизическоеЛицо)" КАК Поле3,
	ПРЕДСТАВЛЕНИЕССЫЛКИ(Пользователи.ФизическоеЛицо) КАК ФизическоеЛицоПредставление,
	"ПРЕДСТАВЛЕНИЕССЫЛКИ(Пользователи.Комментарий)" КАК Поле4,
	ПРЕДСТАВЛЕНИЕССЫЛКИ(Пользователи.Комментарий) КАК КомментарийПредставление
ИЗ
	Справочник.Пользователи КАК Пользователи

Его выполнение на СУБД выглядит так:

 
 SQL-запрос и его реверс

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

А теперь попробуем поработать с полями составного типа. Возьмем регистр сведений ДополнительныеСведения, добавим в него запись со значением поля Свойство - ссылка на элемент справочника _ДемоПартнеры. Используем такой вот запрос:

ВЫБРАТЬ
	ПРЕДСТАВЛЕНИЕ(ДополнительныеСведения.Значение) КАК Значение1
ИЗ
	РегистрСведений.ДополнительныеСведения КАК ДополнительныеСведения

На выходе получаем два запроса - плоский запрос ко всем возможным полям свойства (оно ведь составное). И для получения представления выполняется еще один запрос, сходный с тем, которые используются для представлений ссылок ТЧ (см.выше).

 
 Запросы в профайлере
 
 Реверс

Собственно, вот и ответ - почему ПРЕДСТАВЛЕНИЕ не является обычной строкой для манипуляций в языке запросов 1С. В основном запросе нет никаких соединений со справочником _ДемоПартнеры для получения каких-то текстовок, нет конструкций с использованием ISNULL(...) или CASE. Наше ПРЕДСТАВЛЕНИЕ вычисляется в результате пост-обработки результатов запросов уже на стороне платформы.

 

КОНЕЦПЕРИОДА (из языка запросов)

Итоговая конструкция функции КОНЕЦПЕРИОДА(&Дата, День) выглядит так:

DATEADD(SECOND,@P3,DATEADD(MINUTE,@P4,DATEADD(HOUR,@P5,DATEADD(DAY,CAST(DATEPART(DAY,@P6) КАК NUMERIC(4)) - 1,DATEADD(MONTH,CAST(DATEPART(MONTH,@P7) КАК NUMERIC(4)) - 1,DATEADD(YEAR,CAST(DATEPART(YEAR,@P8) КАК NUMERIC(4)) - 2000,@P9)))))))

Мда, несколько монструозно. Видим примерно следующую логику: к дате 01.01.2000 добавляются составляющие года (минус 2000), месяца и дня из переданной даты, и добавляется время 23:59:59. 

 

Заключение

На текущий момент исследования трансляции работы механизмов платформы на СУБД - закончены. Полученные сведения, конечно, не перевернули картину мира:) Но все-таки было достаточно интересно покопаться в деталях.

77

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. tormozit 5548 28.02.19 07:21 Сейчас в теме
Рекомендую изучение подобной темы начинать с описания работы кэшей на ИТС:
- Объектный кэш
- Транзакционный кэш
- Кэш представлений ссылок
Также полезно техножурналом смотреть сначала запросы модели базы данных (SDBL), т.к. в них меньше "мусора" и лучше видна логика работы платформы.
Rustig; Danil.Potapov; Sanya1984; Vladimir Litvinenko; Jestery; asdf_88; kalyaka; jif; +8 Ответить
2. ImHunter 156 28.02.19 07:28 Сейчас в теме
(1) Это все понятно:) Но мое стремление было - увидеть своими глазами, что делает СУБД. Ибо документация может и не отражать всех особенностей.
4. tormozit 5548 28.02.19 09:10 Сейчас в теме
Своими глазами ты например не увидел проверку в СУБД версии данных при обращении к объекту, находящемуся в объектном кэше.
5. ImHunter 156 28.02.19 09:19 Сейчас в теме
(4) Видел вполне себе... Все-пре-все наблюдения - не было целью описать.
6. tormozit 5548 28.02.19 09:22 Сейчас в теме
(5) Ну статья же вроде обещает рассказать "что при этом делает СУБД". Считаю, что без упоминания запроса проверки версии данных статья лишена важного элемента.
buganov; zhichkin; headMade; +3 Ответить
7. ImHunter 156 28.02.19 09:24 Сейчас в теме
(6) Принято. Подумаю, как дополнить. Но с другой стороны, такими проверками особо не порулить.
16. VVi3ard 48 10.04.19 17:50 Сейчас в теме
Статья как уже заметил (1) не достаточно объективная.

Что решит обычный разработчик прочитав ее?
"Получать через точку не выгодно".

А на самом деле зачастую выгоднее получать через "." особенно если объект это какой то НСИ который редко меняется.
Т.к. с высокой долей вероятности значение всех полей уже есть в кэше и чтение из БД не потребует чтения из базы.
В то время как использование функций БСП гарантированно приводит к чтению данных.

Так например обращение к реквизиту формы через "." с вероятностью 90% приведет к чтению кэша а не к получению данных из ИБ.


Думаю что для полноты статьи нужно провести эксперименты с учетом кэширования.
26. buganov 57 07.06.19 12:58 Сейчас в теме
(16) Уот так уот, оказывается методами БСП невыгодно получать реквизит. Нонсенс!
Давайте поможем Даше получить оптимальнее контрагента из ссылки на заказ.
Вариант 1. Через точку. При этом считаются все реквизиты, табличные части из СУБД. В лучшем случае из кеша. Но в кеш то надо еще получить!
Вариант 2. Управляемый. С помощью запроса за 3 мс получить значение нужного реквизита без мусора. Гарантировано всегда быстро.

Ах да, писатели типовых ведь сплошь стажеры, придумали фигню, лучше бы всю базу в кеш затолкали, а чего, быстро же будет!
shalimski; mickey.1cx; +2 2 Ответить
3. w.r. 459 28.02.19 08:38 Сейчас в теме
Как бы известно, что если по ссылке получаешь реквизит, например:

ЗаказСсылка.Номер

то из СУБД считывается целиком объект со всеми реквизитами и табличными частями

поэтому, если нужно считать 1 или несколько реквизитов из сложного объекта, типа документа, то рекомендуют делать это через Запрос

https://its.1c.ru/db/metod8dev/content/2717/hdoc
Rustig; asdf_88; +2 Ответить
8. Glebis 11 28.02.19 09:27 Сейчас в теме
А какие поля опрашиваются при вызове метода "Представление" в запросе?
anton3077944; +1 Ответить
9. ImHunter 156 28.02.19 09:29 Сейчас в теме
(8) Точно! Хотел ведь глянуть итоговый такой запрос. К концу сегодня (28.02) докину пример.
anton3077944; +1 Ответить
12. Darklight 19 28.02.19 10:08 Сейчас в теме
(9)Не забудьте заодно и про метод "ПРЕДСТАВЛЕНИЕССЫЛКИ" и про свойство ".Представление"
anton3077944; +1 Ответить
11. Darklight 19 28.02.19 10:05 Сейчас в теме
10. Darklight 19 28.02.19 10:00 Сейчас в теме
Про обращение к константе добавь
Про разделители напиши
Про то, как изменятся запрос при применении RLS тоже важно было бы упомянуть
13. strek_ivan 45 28.02.19 12:19 Сейчас в теме
В БСП с целью оптимизации обращения с СУБД как раз и используется
ОбщегоНазначения.ЗначениеРеквизитаОбъекта(Ссылка, ИмяРеквизита, ВыбратьРазрешенные = Ложь).

Не пренебрегайте этой функцией и, тем самым, сократите время выполнения кода.
Rustig; user764477; Jestery; +3 Ответить
15. user710334_koshil.v 20.03.19 12:15 Сейчас в теме
Попытался. В самописную конфу вставил функцию из БСП.
Задача: приСозданииНаСервере() в реквизит "кладовщик" прописать значение реквизита "сотрудник" справочника "Пользователи". Ссылка на пользователя находится в параметре сеанса "ТекущийПользователь":

p.s. неудачно скриншоты получились.
Там где обращение тупо кладовщикВыдачи = ПараметрыСеанса.ТекущийПользователь.Сотрудник время 0,003309, а там где КладовщикВыдачи = ОбщегоНазначения.ЗначениеРеквизитаОбъекта(ПараметрыСеанса.ТекущийПользователь,"Сотрудник"); время 0,039332 - ровно на порядок. Может пример неудачный?
Прикрепленные файлы:
14. ImHunter 156 28.02.19 17:34 Сейчас в теме
Дописал про ПРЕДСТАВЛЕНИЕССЫЛКИ / ПРЕДСТАВЛЕНИЕ.
zhichkin; Evg-Lylyk; +2 Ответить
17. acanta 64 10.04.19 18:05 Сейчас в теме
Кэширование повышает риск недостоверности данных. оптимизируется не скорость, а надежность.
18. vasilev2015 1382 04.06.19 11:52 Сейчас в теме
Здравствуйте !

я не верю, что Сообщить(Строка(Валюта)); не считывает весь объект. Вы запускали эту команду первой, или Вы запускаете ее, когда объект помещен в кэш ?
19. ImHunter 156 04.06.19 12:54 Сейчас в теме
(18) Я писал в публикации, что при нескольких разыменованиях используется кеширование.
А вообще, я вопрос не понял. Во что вы таки не верите?
20. vasilev2015 1382 04.06.19 13:01 Сейчас в теме
(19) я считаю, что Сообщить(Строка(Валюта)); должен считать весь объект, если раньше не было объектного чтения для переменной "Валюта". Profiler мне пока недоступен.
21. ImHunter 156 04.06.19 13:23 Сейчас в теме
(20) Ну не знаю:) Запросы из профайлера, вам, видимо, не аргумент. Но и ваш аргумент "не верю" - слабоват. Поэтому либо верьте, либо не верьте, либо проверяйте тех.журналом.
22. vasilev2015 1382 04.06.19 13:30 Сейчас в теме
(21) запросы из Профайлера для меня нормальный аргумент. Я просто спрашиваю: было ли перед командой Сообщить(Строка(Валюта)) объектное чтение переменной Валюта или нет ?
23. ImHunter 156 04.06.19 13:37 Сейчас в теме
(22) Нет, конечно. Ведь основная цель была не в исследовании кеширования.
27. gubanoff 46 10.06.19 17:37 Сейчас в теме
(18) для случая Сообщить(Валюта) точно не считывает - в этом случае платформа понимает, что нужно получить только представление объекта, оно кэшируется. А вот для случая преобразования в строку - это вопрос, но он по сути не имеет смысла, т.к. этот код в любом случае методическая ошибка.
24. dock 35 07.06.19 01:40 Сейчас в теме
Хотелось бы такой же проверки для более новых версий платформы (8.3.14 - 8.3.15)
Могу ошибаться, но вроде как обещали изменить поведение при чтении стандартных реквизитов (номер, дата и т.д.)
25. ImHunter 156 07.06.19 06:10 Сейчас в теме
(24) Про изменение поведения тоже краем уха слышал. Для себя спланировал, что как выйдет следующий релиз 14 платформы (после 1779), так и займусь.
Оставьте свое сообщение