Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 8 общая

Долгий запрос по журналу документов. Расшифруйте, пожалуйста, план запроса.

[H A D G E H O G s, 09.08.21 - 22:46]
Долгий запрос по журналу документов. Расшифруйте, пожалуйста, план запроса.
Я
   ptiz
 
09.08.21 - 13:25
Долгий запрос по журналу документов.

Вот такой план запроса:
https://disk.yandex.ru/i/N2MUCRsS0gZzTw

Текст тут:
https://disk.yandex.ru/d/yhYQKslhFK7rRQ

Выполняется почти минуту, документов в журнале более 10 млн., отбор по двум проиндексированным полям.
Можно ускорить?
Статистику обновлял (но без fullscan).
   ptiz
 
1 - 09.08.21 - 13:26
Сам запрос формируется платформой при листании в списке журнала (ОФ).
   Волшебник
 
Модератор
2 - 09.08.21 - 13:27
Текста нет
   Вафель
 
3 - 09.08.21 - 14:08
скорее всего что-то есть в привыводе
   ptiz
 
4 - 09.08.21 - 14:17
(2) Текст самого запроса?
Думал, плана достаточно.
Вот:

SELECT TOP 44
T1._Date_Time,
T1._Number,
T1._Fld7839RRef,
T1._Fld7849RRef,
T1._Fld10451,
T1._Fld17794,
T1._Fld7848RRef,
T1._Fld17793,
T1._Fld7841,
T1._Fld7850RRef,
T1._Fld7840RRef,
T1._Fld17792,
T1._Fld10524,
T1._DocumentTRef,
T1._DocumentRRef,
T1._Marked,
T1._Posted,
T2._Description,
T3._Description,
T4._Description,
T5._Description
FROM _DocumentJournal7838 T1 WITH(NOLOCK)
LEFT OUTER JOIN _Reference31 T2 WITH(NOLOCK)
ON T1._Fld7839RRef = T2._IDRRef
LEFT OUTER JOIN _Reference59 T3 WITH(NOLOCK)
ON T1._Fld7849RRef = T3._IDRRef
LEFT OUTER JOIN _Reference21 T4 WITH(NOLOCK)
ON T1._Fld7850RRef = T4._IDRRef
LEFT OUTER JOIN _Reference101 T5 WITH(NOLOCK)
ON T1._Fld7840RRef = T5._IDRRef
WHERE (T1._Fld7851RRef = P1 AND T1._Fld7848RRef = @P2)
ORDER BY (T1._Date_Time) ASC, (T1._DocumentTRef) ASC, (T1._DocumentRRef) ASC
   ptiz
 
5 - 09.08.21 - 14:19
Меня в плане запроса смущает 13301189 раз вызываемый  |--Clustered Index Seek(OBJECT:([ts].[dbo].[_DocumentJournal7838]....

Правильно смущает?
   Fragster
 
6 - 09.08.21 - 14:29
ну он думал, что строк с отбором по складу будет сильно меньше
   Fragster
 
7 - 09.08.21 - 14:29
вывод - кривая статистик
   Fragster
 
8 - 09.08.21 - 14:31
"13301189 раз вызываемый" - это он отобрал по складу вместо 1 133... строк и прилеплял к нему данные из кластерного индекса для вывода. по идее нужно ударить пользователя по рукам и установить сортировку по дате вместо той, которая у него стоит.
   Вафель
 
9 - 09.08.21 - 14:32
(8) разве сортировка по дате не по умолчанию?
   Вафель
 
10 - 09.08.21 - 14:33
(5) что может быть лучше чем индекс сик? Ничего
   Fragster
 
11 - 09.08.21 - 14:33
(9) по умолчанию. но пользователи любят потыкать в другие поля. а если там накладывается отбор - то возникают спецэффекты
   Fragster
 
12 - 09.08.21 - 14:33
(10) только для случая автора там явно будет лучше скан всей таблицы
   Fragster
 
13 - 09.08.21 - 14:34
без нестедлупса
   Fragster
 
14 - 09.08.21 - 14:34
а, у автора и так по дате, см ORDER BY (T1._Date_Time) ASC, (T1._DocumentTRef) ASC, (T1._DocumentRRef) ASC
   Fragster
 
15 - 09.08.21 - 14:35
тогда ладно, линейку можно убрать... на этот раз
   H A D G E H O G s
 
16 - 09.08.21 - 14:37
Для выкладывающих планы запроса в тексте - отдельный котел.
   ptiz
 
17 - 09.08.21 - 14:41
   H A D G E H O G s
 
18 - 09.08.21 - 15:40
(17) Все нормально. Лучше не получится.

Это фактический или расчетный план? Смущает расхождение ожидаемого и фактического количества данных.

Попробуй Склад индексировать с доп.упорядочиванием.
   Fragster
 
19 - 09.08.21 - 15:45
(18) мне кажется, должно получиться, если оно не будет отбирать все документы по складу, потом прилеплять к ним дату, сортировать и выводить 44 из них. что-то со статистикой. ну, или руками подкрутить индекс по складу, чтоы в него  (T1._Date_Time) ASC, (T1._DocumentTRef) ASC, (T1._DocumentRRef) добавились
   Fragster
 
20 - 09.08.21 - 15:46
как работает индексирование с допупорядочиванием в журналах - я хз. вероятно как раз таким образом.
   Fragster
 
21 - 09.08.21 - 15:46
надо итс открывать, но мне лень.
   H A D G E H O G s
 
22 - 09.08.21 - 15:47
(19) доп упорядочение как раз и добавит
   ptiz
 
23 - 09.08.21 - 15:53
(18) Событие Showplan Statistics Profile - это фактический?
Попробую доп упорядочивание.
   Вафель
 
24 - 09.08.21 - 15:54
так по плану соединение каждого справочника в 3 раза дороже чем чем отбора по складу и поиска полей
   H A D G E H O G s
 
25 - 09.08.21 - 15:55
(23) Оно. Но если это то, что ты выложил - у тебя статистика неактуальна.
   H A D G E H O G s
 
26 - 09.08.21 - 15:56
(24) Не разочаровывайте меня, Анатолий.
   Вафель
 
27 - 09.08.21 - 15:56
а нет, там же нарстающим итогом цена
   ptiz
 
28 - 09.08.21 - 15:59
(25) Неактуальна по каким таблицам?
   Fragster
 
29 - 09.08.21 - 16:00
(28) журнала доков
   ptiz
 
30 - 09.08.21 - 16:01
(29) Сделал UPDATE STATISTICS _DocumentJournal7838 with fullscan - быстрее не стало
 
 
   Fragster
 
31 - 09.08.21 - 16:02
(30) так надо кэш планов сбросить
   Fragster
 
32 - 09.08.21 - 16:02
после жтого
   H A D G E H O G s
 
33 - 09.08.21 - 16:13
(31) Да бесполезно.
Сейчас у SQL 2 пути 

- найти в некластерном все записи склада, многомилионов keylook-upпом поглядеть в кластерном дату, время, ссылку и по ней сортировать эту йобу и затем вытащить 44 записи из этого. Это сейчас мы видим в плане.
- Пройтись по кластерному многомиллионов записей, выбирая записи со складами, и дождаться 44 накопленных записи. Но SQL не знает, как быстро найдутся эти записи и делать так не будет, так как читать кластерный тяжело.

Когда мы добавим до упорядочивание, возможно, SQL удовлетворится выборкой 44 записей результата поиска по некластерному, не подглядывая в кластерный.
   ptiz
 
34 - 09.08.21 - 16:15
Спасибо. Вечером запущу реструктуризацию, потом доложусь.
   Fragster
 
35 - 09.08.21 - 16:17
(33) не, ну там, вроде, есть статистика по равномерности значений. и тогда он может понять, что для получения 44 записей ему достаточно будет отсканить 1000 записей кластерного...
   H A D G E H O G s
 
36 - 09.08.21 - 16:21
(35) Инфу в студию. В статистику по кластерному индексу только ссылка и входит.
Но если ты покажешь гистограмму с расшифровкой, вопрос будет снят :-)
   Fragster
 
37 - 09.08.21 - 16:23
   Fragster
 
38 - 09.08.21 - 16:25
вообще уже давно надо нейросетку туда пихнуть, чтобы она подправляла планы
   Fragster
 
39 - 09.08.21 - 16:25
при сильном различии ожидаемого и реального
   ptiz
 
40 - 09.08.21 - 21:00
После индексирования с доп.упорядочиванием - летает!
https://disk.yandex.ru/i/iGw0OM6Pvlgn8g
   H A D G E H O G s
 
41 - 09.08.21 - 22:46
(40) А скинь xml-ку
   Ёпрст
 
42 - 09.08.21 - 22:48
(41) всё забываю спросить, китайщину то внедрили ?
Тоскливо, но думаю, как-ить тоже придётся архив лепить.
   H A D G E H O G s
 
43 - 09.08.21 - 23:01
(42) Внедрили. Работает.
   Ёпрст
 
44 - 09.08.21 - 23:32
(43) я пробовал подменять на-ходу обычную марку на китайщину во всех реквизитах. Красиво не получилось. Как вы реализовали, если сканят марку в реквизит, и надо быстро найти ее значение, если она уже в базе как китайщина ?
   H A D G E H O G s
 
45 - 09.08.21 - 23:39
(44) В элементе справочника Марки храню md5-хеш кода марки.

Если не нашли по коду марки - ищем по md-5 хешу марки.

md-5 получаю в  виде строки так:
Функция ПолучитьХешМарки(КодМарки) Экспорт
    Хеширование=Новый ХешированиеДанных(ХешФункция.MD5);
    Хеширование.Добавить(КодМарки);
    ДвоичныеДанныеХеша=Хеширование.ХешСумма;
    Возврат ПолучитьСтрокуИзДвоичныхДанных(ДвоичныеДанныеХеша, "UTF-16LE");
КонецФункции
   H A D G E H O G s
 
46 - 09.08.21 - 23:39
(44) Ну и код марки восстанавливаю, делая ее обычной маркой.
   Ёпрст
 
47 - 10.08.21 - 08:08
(45) ага, спасибо
   ptiz
 
48 - 10.08.21 - 09:01
(41) https://disk.yandex.ru/d/0s2KT22BGSzjhw
А каким инструментом её смотришь?
   H A D G E H O G s
 
49 - 10.08.21 - 10:58
(48) MS SQL Enterprise manager
   Ёпрст
 
50 - 10.08.21 - 13:14
(48)SentryOne PlanExplorer неплох
   Роспотребнадзор
 
51 - 10.08.21 - 14:05
(40) а текст запроса не изменился?
   Роспотребнадзор
 
52 - 10.08.21 - 14:31
Всё-таки не понятно, почему изначально начал искать в индексе _Docume7838_ByField16028_RR по полю _Fld7848RRef - это точно склад а не статус?

Потому что после добавления индекса по складу с доп. упорядочиванием условие по складу устанавливается по полю _Fld7851RRef

Оч странно что такая ошибка была изначально в оценке строк...
   Роспотребнадзор
 
53 - 10.08.21 - 14:36
(40) куда пропало условие по второму полю?
   Конструктор1С
 
54 - 10.08.21 - 14:47
(0) WHERE (T1._Fld7851RRef = P1 AND T1._Fld7848RRef = @P2)

что за поля?
   ptiz
 
55 - 10.08.21 - 15:00
(51) Не менялся. Всё так же ставится отбор в журнале.

(53) Да вроде не пропал. Проверил еще раз - запрос такой же.

(54) Справочник и перечисление.


В общем, на ИТС всё написано, просто не знал:
"В варианте "Индексировать с доп. упорядочиванием" в динамическом списке может быть обеспечен эффективный просмотр больших объемов информации с отбором по значению данного реквизита и с упорядочиванием, соответствующим основному упорядочиванию для данного объекта. В этом случае наличие индекса включающего реквизит, по которому выполняется отбор, и поля основного упорядочивания позволит системе использовать индекс при просмотре списка."
https://its.1c.ru/db/metod8dev/content/2742/hdoc
   Роспотребнадзор
 
56 - 10.08.21 - 15:08
(55)
>>Справочник и перечисление.

Тогда у тебя в первом запросе сначала шел поиск по перечислению, а не по складу


(55) во втором плане где у тебя поиск по _Fld7848RRef?
   ptiz
 
57 - 10.08.21 - 15:32
(56)  Еще раз проверил.
Запрос:
SELECT TOP 44
T1._Date_Time,
T1._Number,
T1._Fld7839RRef,
T1._Fld7849RRef,
T1._Fld10451,
T1._Fld17794,
T1._Fld7848RRef,
T1._Fld17793,
T1._Fld7841,
T1._Fld7850RRef,
T1._Fld7840RRef,
T1._Fld17792,
T1._Fld10524,
T1._DocumentTRef,
T1._DocumentRRef,
T1._Marked,
T1._Posted,
T2._Description,
T3._Description,
T4._Description,
T5._Description
FROM _DocumentJournal7838 T1 WITH(NOLOCK)
LEFT OUTER JOIN _Reference31 T2 WITH(NOLOCK)
ON T1._Fld7839RRef = T2._IDRRef
LEFT OUTER JOIN _Reference59 T3 WITH(NOLOCK)
ON T1._Fld7849RRef = T3._IDRRef
LEFT OUTER JOIN _Reference21 T4 WITH(NOLOCK)
ON T1._Fld7850RRef = T4._IDRRef
LEFT OUTER JOIN _Reference101 T5 WITH(NOLOCK)
ON T1._Fld7840RRef = T5._IDRRef
WHERE (T1._Fld7851RRef = P1 AND T1._Fld7848RRef = @P2)
ORDER BY (T1._Date_Time) ASC, (T1._DocumentTRef) ASC, (T1._DocumentRRef) ASC



План к нему:
https://disk.yandex.ru/d/fT1bqqXiWncsgw
   Роспотребнадзор
 
58 - 10.08.21 - 16:18
(57) Сейчас да, поиск идет по двум полям. Но кажется что созданный индекс (кот. с доп. упорядочиванием) не при чем, т.к. в плане он не используется. Точнее его создание помогло в том плане что произошла реструктуризация, обновились индексы и старый кривой план был удален из кэша и и для этой таблицы был сформирован новый план. Почему был изначально кривой план сложно сказать, как вариант - для журнала был установлен отбор по какому-то очень редкому значению статуса, этот план закэшировался и потом из-за parameter sniffing стал использоваться для всех других значений перечисления.
   ptiz
 
59 - 10.08.21 - 18:43
(58) Убрал индексирование с доп.упорядочиванием - снова список умирает.
   ДенисЧ
 
60 - 10.08.21 - 18:51
(59) Теперь ты знаешь, как убить динсписок ))
 
 
   H A D G E H O G s
 
61 - 10.08.21 - 18:51
(59) Базу выложить нет возможности?
   Роспотребнадзор
 
62 - 10.08.21 - 18:53
(60) Это же не динсписок, у него ОФ.
   ptiz
 
63 - 10.08.21 - 18:55
(61) Нет.
Погоняю еще.
   H A D G E H O G s
 
64 - 10.08.21 - 18:55
(62) Это форма списка журнала документов, Михаил. Там запрос то почти такой же, как в динсписке.
   ДенисЧ
 
65 - 10.08.21 - 18:55
(62) А какая разница, если можно убить? )))
   Роспотребнадзор
 
66 - 10.08.21 - 19:02
(59) А покажи плиз состав индекса _Docume7838_ByDocDate_TR
а) до индексирования реквизита с доп. упорядочиванием
б) после включения индексирования реквизита с доп. упорядочиванием
   Конструктор1С
 
67 - 10.08.21 - 19:07
(56) мало инфы. Опиши подробнее, покажи структуру хранения (с индексами)
   ptiz
 
68 - 10.08.21 - 21:30
Итого:
- включаю индексирование с доп.упорядочиванием только по статусу - летает
- включаю индексирование с доп.упорядочиванием только по складу - тормозит

Наверное так звезды сошлись для этой базы.

(в тексте запроса выше: _Fld7851RRef - склад (справочник), _Fld7848RRef - статус документа (перечисление))

(66) _Docume7838_ByDocDate_TR - там _Date_Time, _DocumentTRef, _DocumentRRef. Индекс стандартный для всех журналов.

Большое спасибо H A D G E H O G s  за просвещение!


Список тем форума
 
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.