Учитывая, сколько нового я узнала из комментариев к предыдущей моей публикации, не могу не продолжить свой цикл статей по оптимизации. Критика и комментарии приветствуются.
На этот раз посмотрим оптимизацию запроса. Итак, имеется ЗУП версии 2.5.319.1 СУБД - MS SQL Платформа версии 8.3.14.1565 режим совместимости 8.2.13
От пользователей поступили жалобы на долгое формирование печатной формы Т13 из документа "Табель учета рабочего времени". Проверяем работу на тестовой базе под полными правами.
Включаем замер производительности, и в топ вылезает выполнение запроса.
Аж 34 секунды! Этот запрос растянулся больше, чем на 1000 строк, и понять без профайлера, где проблема, невозможно.
Данные, собранные подсистемой оценки производительности:
Как видно, apdex болтается где-то на дне. (Какая милая опечатка "дукумент"!) А среднее время выполнения операции на рабочей базе 25 секунд.
Итак, для настройки профайлера узнаем ID базы:
Use [database]
Go
Select DB_ID()
Настроим профайлер, выбрав необходимые события и установив отборы по длительности и ID базы:
На этот раз запрос выполнился быстрее, за 9 секунд. Находим самый тяжелый запрос:
Находим его в базе 1с:
ВЫБРАТЬ РАЗРЕШЕННЫЕ
ГрафикиРаботыПоВидамВремени.ГрафикРаботы КАК ГрафикРаботы,
ГрафикиРаботыПоВидамВремени.Дата КАК Дата,
НАЧАЛОПЕРИОДА(ГрафикиРаботыПоВидамВремени.Дата, МЕСЯЦ) КАК ПериодРегистрации,
ГрафикиРаботыПоВидамВремени.ОсновноеЗначение,
ГрафикиРаботыПоВидамВремени.ВидУчетаВремени КАК ВидУчетаВремени,
ГрафикиРаботыПоВидамВремени.Документ,
ГрафикиРаботыПоВидамВремени.План КАК План
ПОМЕСТИТЬ ВТГрафикиРаботыПоВидамВремени
ИЗ
РегистрСведений.ГрафикиРаботыПоВидамВремени КАК ГрафикиРаботыПоВидамВремени
ГДЕ
ГрафикиРаботыПоВидамВремени.ГрафикРаботы В
(ВЫБРАТЬ
Сотрудники.Сотрудник
ИЗ
ВТСотрудники КАК Сотрудники
ОБЪЕДИНИТЬ ВСЕ
ВЫБРАТЬ
ГрафикиРаботников.ГрафикРаботы
ИЗ
ВТГрафикиРаботников КАК ГрафикиРаботников)
И ГрафикиРаботыПоВидамВремени.Дата МЕЖДУ &НачалоПериода И &КонецПериода
И ГрафикиРаботыПоВидамВремени.ВидУчетаВремени <> ЗНАЧЕНИЕ(Перечисление.ВидыУчетаВремени.ПоДням)
Посмотрим структуру регистра сведений. Непериодический, независимый со следующими измерениями:
Казалось бы, как оптимизировать этот запрос? Он написан согласно рекомендациям от 1С, но индекс почему-то не используется, хотя стоят условия по первому измерению. Но ради эксперимента, давайте перепишем запрос, используя "ИЛИ":
ВЫБРАТЬ РАЗРЕШЕННЫЕ
ГрафикиРаботыПоВидамВремени.ГрафикРаботы КАК ГрафикРаботы,
ГрафикиРаботыПоВидамВремени.Дата КАК Дата,
НАЧАЛОПЕРИОДА(ГрафикиРаботыПоВидамВремени.Дата, МЕСЯЦ) КАК ПериодРегистрации,
ГрафикиРаботыПоВидамВремени.ОсновноеЗначение,
ГрафикиРаботыПоВидамВремени.ВидУчетаВремени КАК ВидУчетаВремени,
ГрафикиРаботыПоВидамВремени.Документ,
ГрафикиРаботыПоВидамВремени.План КАК План
ПОМЕСТИТЬ ВТГрафикиРаботыПоВидамВремени
ИЗ
РегистрСведений.ГрафикиРаботыПоВидамВремени КАК ГрафикиРаботыПоВидамВремени
ГДЕ
ГрафикиРаботыПоВидамВремени.ГрафикРаботы В
((ВЫБРАТЬ
Сотрудники.Сотрудник
ИЗ
ВТСотрудники КАК Сотрудники) или
ГрафикиРаботыПоВидамВремени.ГрафикРаботы В(ВЫБРАТЬ
ГрафикиРаботников.ГрафикРаботы
ИЗ
ВТГрафикиРаботников КАК ГрафикиРаботников))
И ГрафикиРаботыПоВидамВремени.Дата МЕЖДУ &НачалоПериода И &КонецПериода
И ГрафикиРаботыПоВидамВремени.ВидУчетаВремени <> ЗНАЧЕНИЕ(Перечисление.ВидыУчетаВремени.ПоДням)
И что же мы видим?
Выполнение запроса меньше чем за секунду.
Текст запроса на языке SQL:
Индекс используется:
После обновления в рабочей базы:
Аpdex по этой операции вырос до 0,914. Среднее время выполнения операции - 3 секунды.
Послесловие
На самом деле это не первый запрос в моей практике, где "ИЛИ" работает лучше чем "ОБЪЕДИНИТЬ ВСЕ". Почему оптимизатор не использовал индекс, ведь условие подходит? У меня есть предположение, что это зависит от версии СУБД. Но это только предположение, если у кого есть идеи лучше, пишите в комментариях.
