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

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

Оптимизация SQL запроса
Я
   Gera1t
 
21.09.21 - 13:28
Конфигурация УНФ 1.6.19.215
Использую характеристики номенклатуры и доп реквизиты характеристик.
Допреквизиты это табличная часть элемента справочника характеристики.
В этой ТЧ есть колонки Свойство и Значение
Характеристик много.
Нужно быстро находить характеристику по допреквизиту.
Пользовался запросом по ТЧ справочника характеристики.

        ВЫБРАТЬ
            ХарактеристикиНоменклатурыДополнительныеРеквизиты.Ссылка КАК Ссылка
        ИЗ
            Справочник.ХарактеристикиНоменклатуры.ДополнительныеРеквизиты КАК ХарактеристикиНоменклатурыДополнительныеРеквизиты
        ГДЕ
            ХарактеристикиНоменклатурыДополнительныеРеквизиты.Свойство = &Свойство
            И ХарактеристикиНоменклатурыДополнительныеРеквизиты.Значение = &Значение

Вот такой запрос.
Задаю параметры Свойство и Значение и получаю ссылку на элемент справочника.
Но по мере роста элементов справочника скорость поиска замедляется
Подскажите пожалуйста как можно оптимизировать процесс поиска что бы увеличить скорость.
Не чего в голову не приходит.
Спасибо!
   H A D G E H O G s
 
1 - 21.09.21 - 13:29
Индексировать колонку Значение.
   Gera1t
 
2 - 21.09.21 - 13:30
Есть мысль создать регистр и писать туда нужные данные и ссылку на элемент справочника, потом искать не в ТЧ справочника, а в регистре.
Но что то изврат какой то
   Gera1t
 
3 - 21.09.21 - 13:30
(1) Да, она не индексируется. Попробую. Спасибо.
   Gera1t
 
4 - 21.09.21 - 13:32
(1) А если внесу изменения через расширение сработает? И как проверить что это работает?
   pechkin
 
5 - 21.09.21 - 13:34
по хорошему бы добавить составной индекс. но такого увы нельзя.
если уж коцать, то лучше реквизит в справочник добавить
   ManyakRus
 
6 - 21.09.21 - 13:36
надо писать ВЫРАЗИТЬ(-:)
   pechkin
 
7 - 21.09.21 - 13:36
(6) не нужно
   Конструктор1С
 
8 - 21.09.21 - 13:37
(1) может лучше индексировать Свойство? Значение скорее всего составного типа. Платформа нафигачит по нему лишних индексов (на каждый примитивный тип по индексу, плюс индекс для ссылочных типов)
   pechkin
 
9 - 21.09.21 - 13:38
(8) так свойство наверняка у каждой характеристики есть
   H A D G E H O G s
 
10 - 21.09.21 - 13:41
(8) нет
   Gera1t
 
11 - 21.09.21 - 13:42
(1) Не включается индексировать, появляется ошибка.
   Gera1t
 
12 - 21.09.21 - 13:46
Но, индексировал колонку Свойство и произошло чудо, скорость выполнения запроса выросла в 22 раза.
Вот только как это скажется на размере базы?
   Конструктор1С
 
13 - 21.09.21 - 13:51
(9) не факт. Кстати, индексируя поле составного типа, в котором есть примитивные типы, можно попасть в хитрую платформенную ловушку. Платформа в SQL-запрос неявно добавляет отборы по примитивным полям составного типа

WHERE
...
and <Поле даты> = 'пустаядата'
and <Поле строки> = ''
and <Поле числа> = 0

из-за этого скуль начинает творить трэш, ибо индексы по этим полям есть, но как правило они не селективные. Производительность сразу в труху
   Конструктор1С
 
14 - 21.09.21 - 13:52
(12) почти не скажется
   acht
 
15 - 21.09.21 - 14:27
(13) Ты хочешь сказать, что в этом случае для индексации одного поля 1С создается несколько индексов SQL?
   Конструктор1С
 
16 - 21.09.21 - 14:46
(15) да. По крайней мере так было в 8.2. А в более старых платформах, может ранние 8.2 или 8.1, если в субконто добавить поле примитивного типа, то платформа создавала 100500 лишних индексов
   mistеr
 
17 - 21.09.21 - 14:49
(13) Скуль начинает творить трэш, когда у него нет актуальной статистики.
   youalex
 
18 - 21.09.21 - 14:49
(16) + там еще если статистика неактуальная, то скуль  для поиска ссылки может выбрать "числовой" индекс.
   xkanix
 
19 - 21.09.21 - 14:59
(15) Давно уже нет.
Но если база древняя и в ней никогда не делали полную реструктуризацию - могут ещё быть индексы созданные по старой схеме.
   acht
 
20 - 21.09.21 - 16:03
(16) Я посмотрел.
Ты устарел, там уже давно один индекс, типа https://ibb.co/JQ3LLQx
   Dmitrii
 
21 - 21.09.21 - 16:25
Странно. Мне почему-то казалось, что дело не в версии платформы 1С, а в версии MS SQL сервера. На старых версиях SQL платформа создавала множество индексов. Впрочем могу ошибаться.
   Конструктор1С
 
22 - 21.09.21 - 17:58
(20) сейчас один. Но хорошего тоже мало, у тебя в составном индексе вклинилось число
   Конструктор1С
 
23 - 21.09.21 - 17:58
(21) скуль не решает, какие индексы должны быть у таблиц
   H A D G E H O G s
 
24 - 21.09.21 - 18:00
(22) 1С поставит в условие равенство на ноль да и всё.
   acht
 
25 - 21.09.21 - 18:10
(22) > вклинилось число
Ну ты ж сам пример условия в (13) приводил
   МихаилМ
 
26 - 21.09.21 - 18:11
   ДенисЧ
 
27 - 21.09.21 - 18:30
(26) Адвизор != решатель.
Такшта...
   Конструктор1С
 
28 - 21.09.21 - 18:59
(24) это примерно как индекс по организации. Если в табличке 98% записей с одной и той же организацией, то толку от индексирования по полю Организация никакого

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

Регистр №1
Склад    Номенклатура
Склад №1    Товар А
Склад №1    Товар Б
Склад №1    Товар В
Склад №2    Товар А
Склад №2    Товар Б
Склад №2    Товар В
Склад №2    Товар Г
Склад №2    Товар Д

Регистр №2
Число    Склад    Номенклатура
0    Склад №1    Товар А
0    Склад №1    Товар Б
0    Склад №1    Товар В
0    Склад №2    Товар А
0    Склад №2    Товар Б
0    Склад №2    Товар В
0    Склад №2    Товар Г
0    Склад №2    Товар Д


допустим, запросом нужно выбрать Товар Б на Склад №1

условно ползём по составному индексу регистра №1 (Склад + Номенклатура): -> 3 записи Склад №1-> 1 запись Товар Б
условно ползём по составному индексу регистра №2 (Число + Склад + Номенклатура): -> 7 записей 0 -> 3 записи Склад №1 -> 1 запись Товар Б

чувствуешь лишние движения? К слову, самым эффективным было бы вот такое следование изменений

Номенклатура    Склад
Товар А        Склад №1
Товар Б        Склад №1
Товар В        Склад №1
Товар А        Склад №2
Товар Б        Склад №2
Товар В        Склад №2
Товар Г        Склад №2
Товар Д        Склад №2

тогда вхуж по индексу будет выглядеть так: -> 2 записи Товар Б -> 1 запись Склад №1
   Конструктор1С
 
29 - 21.09.21 - 19:03
примерно так губят индекс беспонтовые незаполненные поля. А когда у тебя поле составного типа, то в середине индекса вклиниваются поля примитивных типов, которые с вероятностью 95% обречены быть незаполненными
   H A D G E H O G s
 
30 - 21.09.21 - 20:31
 
 
   H A D G E H O G s
 
31 - 21.09.21 - 20:35
(28) Рекомендую почитать про индексы.
   H A D G E H O G s
 
32 - 21.09.21 - 20:50
(28) Вот тестовая конфигурашечка,
https://disk.yandex.ru/d/45CNPsUPHvTkjg

В тестовой обработке понажимай кнопки, и посмотри на планы запросов по кнопкам "Запрос к первому регистру" и "Запрос к второму регистру"
   acht
 
33 - 21.09.21 - 22:21
(28) > условно ползём по составному индексу

Дяденька, а можно я вам не буду рассказывать, что индекс в сбалансированных деревьях хранится? Спасибо большое!
   pechkin
 
34 - 21.09.21 - 22:34
(33) это не отменяет факта что высокоселективные поля лучше первыми в индексе иметь
   acht
 
35 - 21.09.21 - 22:36
(34) Да, но это всего лишь уменьшает глубину просмотра, а не "ползём по индексу"
   Конструктор1С
 
36 - 22.09.21 - 04:04
(32) и что план? План может выдать Index Seek, а запрос всё равно будет тупым. Видимо у тебя нет опыта работы с большими БД, раз ты так бравируешь планами запросов

(33) дяденька, давай я не буду тебе рассказывать про селективность индекса?

(35) ты заблуждаешься
   H A D G E H O G s
 
37 - 22.09.21 - 12:46
(36) Вам бы еще про чтение планов запросов почитать.

**записал Конструктор1С в списочек.
   acht
 
38 - 22.09.21 - 12:54
(37) > Конструктор1С

Возрастное ограничение: от трех до пяти лет =)
   ДенисЧ
 
39 - 22.09.21 - 12:54
(38) "А я за час собрал!"
   H A D G E H O G s
 
40 - 22.09.21 - 12:55
(36) IndexSeek может быть плох, когда у него есть остаточный предикат поиска. Надеюсь, вы в курсе этого.
   H A D G E H O G s
 
41 - 22.09.21 - 13:17
(36) Вот тебе пример остаточного предиката, когда indexseek может быть не так полезен, и это могло нанести травму
https://prnt.sc/1t7ur16

Обновленная база с 3 регистром, где это воспроизводится.
https://disk.yandex.ru/d/45CNPsUPHvTkjg
   Конструктор1С
 
42 - 22.09.21 - 14:32
(40) нет. Index Seek может быть плох и в других случаях, и даже без предиката where. Один из них это фильтр по неселективному полю. Например, в документе индексирован реквизит Организация. Но во всех документах одна и та же организация. Производительность в труху
Второй пример. В таблице есть два индекса, по Организация и Контрагент. В запросе накладывается отбор по обоим полям. НО! В таблице по отбираемому контрагенту 1 тыс. записей, а по отбираемой организации 1 млрд. записей. Скуль бодро отрапортует о двух Index Seek без where, а потом начнёт джойнить их результаты. Производительность снова в труху. Гораздо выгоднее было бы, если бы индекса по организации не было. Тогда Index Seek по контрагенту отобрал бы тыщу, а предикат where быстренько дофильтровал по организации
   H A D G E H O G s
 
43 - 22.09.21 - 15:08
(42) В первом случае индекс не будет использоваться, если в выборке есть поля, отличные от ИНН и Ссылка и это правильно.
И будет использоваться, если есть только эти поля и это тоже правильно.
   H A D G E H O G s
 
44 - 22.09.21 - 15:09
(42) во втором случае - да, такое бывает и это лечится предварительным отбором во временную таблицу по более селективному индексу. Такой себе костыль, но в условиях отсутствия конструктора индексов - шо маемо.


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