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

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

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

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

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

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

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

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

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

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

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

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