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

1. timeforlive 16 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 16 06.12.16 11:01 Сейчас в теме
(3) С практической. У меня вирт. таблица ПродажиОбороты, по ней формирую две ВТ, одна со связью по Возврату, другая по Реализации, а у всех единая связь через ЗаказПокупателя, с учетом различных условий для отбора.

Вот и думаю, что нужно производительность ускоряить, когда отчет сформируют за период - год, где нужно просмотреть, были ли возвраты, по какой номенклатуре и т.д., а база толстая.
5. igel9780 173 06.12.16 11:12 Сейчас в теме
Если упрощённо. Обход таблицы выполняется за линейное время. Обход индекса выполняется за логарифмическое (по основанию 2) время. Поэтому, если у вас в таблице 1000 записей, то в индексе необходимо просмотреть 10 ветвей (в хорошем случае), таблица сканируется целиком (все 1000 записей). При этом, если таблица целиком помещается в памяти, то бинарный поиск по такой таблице выполняется так же за логарифмическое время, при этом нет затрат на переходы между ветвями индекса (то-есть, выгоднее не использовать индекс).
Вывод. Если может быть большой объем данных, то индекс строить надо. А вот воспользуется оптимизатор этим индексом или нет, это уже вопрос к оптимизатору.
6. timeforlive 16 06.12.16 11:17 Сейчас в теме
(5) Можете поделиться источником информации? Похоже там много чего интересного можно узнать, раз столь интересный и познавательный ответ у вас получился!
7. alxarz 31 06.12.16 11:36 Сейчас в теме
(6) так результаты замера производительности с индексированием и без за тот же год можно увидеть?
9. ImHunter 318 06.12.16 12:01 Сейчас в теме
(7) Как вариант, поищи консоль запросов, которая показывает статистику выполнения запросов пакета (время, кол-во записей). Я где-то давно стянул Запросник82.
10. alxarz 31 06.12.16 12:09 Сейчас в теме
(9) человек в (1) предлагает обсудить, я предлагаю выложить ещё и результаты, тем более у него это задача с практической точки и рассматривается.
11. ImHunter 318 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 96 28.03.23 18:25 Сейчас в теме
(5) а за счет чего будут создаваться ветки, если все записи уникальны? По мне так будет одна ветка со всеми записями, что будет идентично отсутствию индекса, прибавим накладные расходы на создание индекса и получается даже медленнее
13. user1880116 28.03.23 19:26 Сейчас в теме
(12) Вот сейчас он, через 7 лет вернется и ответит...
14. user602678_maxipunchik 96 28.03.23 20:45 Сейчас в теме
15. user1880116 28.03.23 21:00 Сейчас в теме
17. igel9780 173 29.03.23 08:04 Сейчас в теме
16. igel9780 173 29.03.23 08:02 Сейчас в теме
(12) Для формирования индекса типа дерево есть только одно условие для типа данных. На типе данных должны быть определены операции больше и меньше (>, <). Всё что меньше данного узла идёт влево, всё что больше - вправо. Опять же есть нюанс, что на практике используются не бинарные деревья, а более другие. Балансированные, например: b-tree и т.п.
Вопрос только в том, сколько мы прогнозируем выбрать из временной таблицы. Если по итогу в выборку попадет большая часть записей, это значит, что мы и индекс весь прочитаем, и временную таблицу в полном объеме. Тогда смысл индекса снижается.
С другой стороны, если временная таблица не помещается в память, а мы её начинаем джойнить с чем-нибудь, то на каждое проверяемое значение начнётся перечитывание закешированных страниц. Здесь опять индекс начинает иметь значение, даже если он в память не очень помещается.
Ну и последнее. Когда вы пишете запрос у вас мало записей в таблице. Через год на проде количество записей вырастет в разы. Делайте индекс, и пусть оптимизатор за вас думает, использовать его или нет.
Dilise; user602678_maxipunchik; +2 Ответить
Оставьте свое сообщение

Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот