Индексировать ВТ с одним полем или нет?
Много говорится об индексировании в запросе, но вот вопрос, который я так и не встретил на примере:
Помещаем во временную таблицу поле с типом "СправочникСсылка.Номенклатура", с произвольным отбором. ВТ имеет несколько тысяч записей, все уникальны.
Естественно, соединение будет по этому полю в дальнейшем.
Теперь вопрос: нужно ли индексировать ВТ в данном случае?
Ведь, исходя из информации с ИТС:
То есть, если индексировать одно поле с уникальными записями, то способ чтения индексированной ВТ будет тот же самый, что и НЕ индексированной ВТ - прямой обход всех записей. Следовательно - индексирование в данном случае лишь замедлит производительность запроса.
Прошу обсудить данную задачу.
Помещаем во временную таблицу поле с типом "СправочникСсылка.Номенклатура", с произвольным отбором. ВТ имеет несколько тысяч записей, все уникальны.
Естественно, соединение будет по этому полю в дальнейшем.
Теперь вопрос: нужно ли индексировать ВТ в данном случае?
Ведь, исходя из информации с ИТС:
Для измерений, реквизитов и т.д. применяются условные имена Измерение1, Реквизит1 и т.д.
Для общих реквизитов, являющихся разделителями в режиме "независимо», будем использовать имена ОРНР (ОРНР1, ОРНР2, и т.д.).
Для общих реквизитов, являющихся разделителями в режиме "независимо», будем использовать имена ОРНР (ОРНР1, ОРНР2, и т.д.).
То есть, если индексировать одно поле с уникальными записями, то способ чтения индексированной ВТ будет тот же самый, что и НЕ индексированной ВТ - прямой обход всех записей. Следовательно - индексирование в данном случае лишь замедлит производительность запроса.
Прошу обсудить данную задачу.
По теме из базы знаний
Ответы
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
(3) С практической. У меня вирт. таблица ПродажиОбороты, по ней формирую две ВТ, одна со связью по Возврату, другая по Реализации, а у всех единая связь через ЗаказПокупателя, с учетом различных условий для отбора.
Вот и думаю, что нужно производительность ускоряить, когда отчет сформируют за период - год, где нужно просмотреть, были ли возвраты, по какой номенклатуре и т.д., а база толстая.
Вот и думаю, что нужно производительность ускоряить, когда отчет сформируют за период - год, где нужно просмотреть, были ли возвраты, по какой номенклатуре и т.д., а база толстая.
Если упрощённо. Обход таблицы выполняется за линейное время. Обход индекса выполняется за логарифмическое (по основанию 2) время. Поэтому, если у вас в таблице 1000 записей, то в индексе необходимо просмотреть 10 ветвей (в хорошем случае), таблица сканируется целиком (все 1000 записей). При этом, если таблица целиком помещается в памяти, то бинарный поиск по такой таблице выполняется так же за логарифмическое время, при этом нет затрат на переходы между ветвями индекса (то-есть, выгоднее не использовать индекс).
Вывод. Если может быть большой объем данных, то индекс строить надо. А вот воспользуется оптимизатор этим индексом или нет, это уже вопрос к оптимизатору.
Вывод. Если может быть большой объем данных, то индекс строить надо. А вот воспользуется оптимизатор этим индексом или нет, это уже вопрос к оптимизатору.
(6)
вообще, это смотрится через SQL Profiler - но это в двух словах не объяснить. нужно изучать науку по оптимизации запросов
наглядно будет видно используется "table scan" или "index seek"
а так да, оптимизатор запросов на маленьких таблицах всё равно не будет использовать индекс даже если он есть
вообще, это смотрится через SQL Profiler - но это в двух словах не объяснить. нужно изучать науку по оптимизации запросов
наглядно будет видно используется "table scan" или "index seek"
а так да, оптимизатор запросов на маленьких таблицах всё равно не будет использовать индекс даже если он есть
(12) Для формирования индекса типа дерево есть только одно условие для типа данных. На типе данных должны быть определены операции больше и меньше (>, <). Всё что меньше данного узла идёт влево, всё что больше - вправо. Опять же есть нюанс, что на практике используются не бинарные деревья, а более другие. Балансированные, например: b-tree и т.п.
Вопрос только в том, сколько мы прогнозируем выбрать из временной таблицы. Если по итогу в выборку попадет большая часть записей, это значит, что мы и индекс весь прочитаем, и временную таблицу в полном объеме. Тогда смысл индекса снижается.
С другой стороны, если временная таблица не помещается в память, а мы её начинаем джойнить с чем-нибудь, то на каждое проверяемое значение начнётся перечитывание закешированных страниц. Здесь опять индекс начинает иметь значение, даже если он в память не очень помещается.
Ну и последнее. Когда вы пишете запрос у вас мало записей в таблице. Через год на проде количество записей вырастет в разы. Делайте индекс, и пусть оптимизатор за вас думает, использовать его или нет.
Вопрос только в том, сколько мы прогнозируем выбрать из временной таблицы. Если по итогу в выборку попадет большая часть записей, это значит, что мы и индекс весь прочитаем, и временную таблицу в полном объеме. Тогда смысл индекса снижается.
С другой стороны, если временная таблица не помещается в память, а мы её начинаем джойнить с чем-нибудь, то на каждое проверяемое значение начнётся перечитывание закешированных страниц. Здесь опять индекс начинает иметь значение, даже если он в память не очень помещается.
Ну и последнее. Когда вы пишете запрос у вас мало записей в таблице. Через год на проде количество записей вырастет в разы. Делайте индекс, и пусть оптимизатор за вас думает, использовать его или нет.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот