|
Оптимизация 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) во втором случае - да, такое бывает и это лечится предварительным отбором во временную таблицу по более селективному индексу. Такой себе костыль, но в условиях отсутствия конструктора индексов - шо маемо.
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |