Индексировать ВТ с одним полем или нет?

1. timeforlive 15 06.12.16 09:55 Сейчас в теме
Много говорится об индексировании в запросе, но вот вопрос, который я так и не встретил на примере:

Помещаем во временную таблицу поле с типом "СправочникСсылка.Номенклатура", с произвольным отбором. ВТ имеет несколько тысяч записей, все уникальны.
Естественно, соединение будет по этому полю в дальнейшем.

Теперь вопрос: нужно ли индексировать ВТ в данном случае?

Ведь, исходя из информации с ИТС:
ИТС: Индексы таблиц базы данных

Для измерений, реквизитов и т.д. применяются условные имена Измерение1, Реквизит1 и т.д.
Для общих реквизитов, являющихся разделителями в режиме "независимо», будем использовать имена ОРНР (ОРНР1, ОРНР2, и т.д.).


То есть, если индексировать одно поле с уникальными записями, то способ чтения индексированной ВТ будет тот же самый, что и НЕ индексированной ВТ - прямой обход всех записей. Следовательно - индексирование в данном случае лишь замедлит производительность запроса.

Прошу обсудить данную задачу.
По теме из базы знаний
Ответы
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
2. Denic_01 46 06.12.16 10:15 Сейчас в теме
не понятно, в принципе, как связаны "индексы таблиц базы данных" с содержимым ВТ

Если создать индексы в ВТ, то таки НЕТ обхода не должно быть, должен быть поиск по созданному индексу.
3. x2z7yy 06.12.16 10:21 Сейчас в теме
Посмотрите время выполнения своего запроса с индексирование, и без. Вопросы отпадут. Если конечно вопрос поставлен с практической точки зрения, а не теоретической.
volkov-mv; +1 Ответить
4. timeforlive 15 06.12.16 11:01 Сейчас в теме
(3) С практической. У меня вирт. таблица ПродажиОбороты, по ней формирую две ВТ, одна со связью по Возврату, другая по Реализации, а у всех единая связь через ЗаказПокупателя, с учетом различных условий для отбора.

Вот и думаю, что нужно производительность ускоряить, когда отчет сформируют за период - год, где нужно просмотреть, были ли возвраты, по какой номенклатуре и т.д., а база толстая.
5. igel9780 171 06.12.16 11:12 Сейчас в теме
Если упрощённо. Обход таблицы выполняется за линейное время. Обход индекса выполняется за логарифмическое (по основанию 2) время. Поэтому, если у вас в таблице 1000 записей, то в индексе необходимо просмотреть 10 ветвей (в хорошем случае), таблица сканируется целиком (все 1000 записей). При этом, если таблица целиком помещается в памяти, то бинарный поиск по такой таблице выполняется так же за логарифмическое время, при этом нет затрат на переходы между ветвями индекса (то-есть, выгоднее не использовать индекс).
Вывод. Если может быть большой объем данных, то индекс строить надо. А вот воспользуется оптимизатор этим индексом или нет, это уже вопрос к оптимизатору.
6. timeforlive 15 06.12.16 11:17 Сейчас в теме
(5) Можете поделиться источником информации? Похоже там много чего интересного можно узнать, раз столь интересный и познавательный ответ у вас получился!
7. alxarz 31 06.12.16 11:36 Сейчас в теме
(6) так результаты замера производительности с индексированием и без за тот же год можно увидеть?
9. ImHunter 312 06.12.16 12:01 Сейчас в теме
(7) Как вариант, поищи консоль запросов, которая показывает статистику выполнения запросов пакета (время, кол-во записей). Я где-то давно стянул Запросник82.
10. alxarz 31 06.12.16 12:09 Сейчас в теме
(9) человек в (1) предлагает обсудить, я предлагаю выложить ещё и результаты, тем более у него это задача с практической точки и рассматривается.
11. ImHunter 312 06.12.16 12:16 Сейчас в теме
(10) Сорри, невнимательно историю читал
8. Denic_01 46 06.12.16 11:47 Сейчас в теме
(6)

вообще, это смотрится через SQL Profiler - но это в двух словах не объяснить. нужно изучать науку по оптимизации запросов
наглядно будет видно используется "table scan" или "index seek"

а так да, оптимизатор запросов на маленьких таблицах всё равно не будет использовать индекс даже если он есть
12. user602678_maxipunchik 95 28.03.23 18:25 Сейчас в теме
(5) а за счет чего будут создаваться ветки, если все записи уникальны? По мне так будет одна ветка со всеми записями, что будет идентично отсутствию индекса, прибавим накладные расходы на создание индекса и получается даже медленнее
13. user1880116 28.03.23 19:26 Сейчас в теме
(12) Вот сейчас он, через 7 лет вернется и ответит...
14. user602678_maxipunchik 95 28.03.23 20:45 Сейчас в теме
15. user1880116 28.03.23 21:00 Сейчас в теме
17. igel9780 171 29.03.23 08:04 Сейчас в теме
16. igel9780 171 29.03.23 08:02 Сейчас в теме
(12) Для формирования индекса типа дерево есть только одно условие для типа данных. На типе данных должны быть определены операции больше и меньше (>, <). Всё что меньше данного узла идёт влево, всё что больше - вправо. Опять же есть нюанс, что на практике используются не бинарные деревья, а более другие. Балансированные, например: b-tree и т.п.
Вопрос только в том, сколько мы прогнозируем выбрать из временной таблицы. Если по итогу в выборку попадет большая часть записей, это значит, что мы и индекс весь прочитаем, и временную таблицу в полном объеме. Тогда смысл индекса снижается.
С другой стороны, если временная таблица не помещается в память, а мы её начинаем джойнить с чем-нибудь, то на каждое проверяемое значение начнётся перечитывание закешированных страниц. Здесь опять индекс начинает иметь значение, даже если он в память не очень помещается.
Ну и последнее. Когда вы пишете запрос у вас мало записей в таблице. Через год на проде количество записей вырастет в разы. Делайте индекс, и пусть оптимизатор за вас думает, использовать его или нет.
Dilise; user602678_maxipunchik; +2 Ответить
Оставьте свое сообщение
Вакансии
Программист 1С
Москва
зарплата от 180 000 руб. до 220 000 руб.
Полный день

Аналитик 1С / Бизнес-аналитик
Нижний Новгород
зарплата от 100 000 руб. до 250 000 руб.
Временный (на проект)

Программист 1С
Москва
зарплата от 250 000 руб.
Полный день

Программист 1C
Волгоград
зарплата от 200 000 руб.
Полный день

Аналитик
Санкт-Петербург
зарплата от 200 000 руб. до 250 000 руб.
Полный день