Дня доброго.
Везде, даже в книге - "Руководство эксперта" встречаю упоминание о том, что во временной таблице надо индексировать колонки, которые будут потом участвовать в соединении.

Не согласен с этим.

Допускаю необходимость индексирования колонок, если по ней будет выполняться соединение n раз, причем это n - надо еще рассчитать, это даже не 2-3 раза, а больше.

Почему так? Рассмотрим случай для соединения по 1-ой колонке:

Ситуация с индексированием:
Для построения индекса по колонке надо построить b+ дерево, а это, как минимум, сортировка значений в этой колонке, обход значений результата и построение дерева, а потом еще и поиск в этом индексе при соединении (а может и не поиск, в зависимости от того, Left или Right Join!, это важно!, тоесть, этот индекс будет бесполезен).

Ситуация без индексирования:
Возьмем, например, (что вероятнее) -  merge-join - это сортировка значений в обоих колонках + обход обоих колонок.

Я правильно понимаю ситуацию?

Кстати, indexscan выбирает уже отсортированные значения?

(25) Индекс скан по скластерному индексу - это обычный тэйбл скан + сортировка

(25) Да, отсортированные, проверил

Итого - Индексы тут оказались нужны только для того, чтобы предварительно не сортировать колонки, так?

ок, бро, счаст заменим Ссылку на Артикул и вернемся.

(27)++++
Хитрый indescan хитро обходит индексное b+ дерево. Респект тебе, ms sql.

ВЫБРАТЬ
    Номенклатура.Артикул
ПОМЕСТИТЬ ВТ
ИЗ
    Справочник.Номенклатура КАК Номенклатура
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    Номенклатура.Код,
    Номенклатура.Наименование
ИЗ
    ВТ КАК ВТ
        ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Номенклатура КАК Номенклатура
        ПО ВТ.Артикул = Номенклатура.Артикул


2 запрос:
TableScan по ВТ + clustered index scan по справочнику Номенклатура (Тоесть, table scan + сортировка).

Но это то и понятно. И логично. Счаст мы немного поменяем запрос.

ВЫБРАТЬ
    Номенклатура.Артикул
ПОМЕСТИТЬ ВТ
ИЗ
    Справочник.Номенклатура КАК Номенклатура
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    ВТ.Артикул
    
ИЗ
    ВТ КАК ВТ
        ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Номенклатура КАК Номенклатура
        ПО ВТ.Артикул = Номенклатура.Артикул


table scan + Index seek по артикулу.

Но самое забавное случается вот сейчас:

ВЫБРАТЬ
    Номенклатура.Артикул КАК Артикул
ПОМЕСТИТЬ ВТ
ИЗ
    Справочник.Номенклатура КАК Номенклатура

ИНДЕКСИРОВАТЬ ПО
    Артикул
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    ВТ.Артикул
ИЗ
    ВТ КАК ВТ
        ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Номенклатура КАК Номенклатура
        ПО ВТ.Артикул = Номенклатура.Артикул


Clustered Index Scan по ВТ + IndexScan по физической таблице. Почему? Потому что sql внезапно решил сделать hash-join!

Теперь попробуем использовать индекс ВТ ПРАВИЛЬНО. Это, суко, очень редкий случай.

Ну например такой вариант
v8: Подзапросы с Выбрать Первые

merge-join  очень эффективный метод соединения.

Нет, не получается.

При попытках смены leftjoin на rightjoin, будет все равно indexscan по ВТ. Потому что sql лепит hash-join. Ладно бы ВТ была мелкая, по она равна физической таблице.

Или тут размер абсолютный имеет значение?

У меня спр. Номенклатур 7500 строк. Из за этого может быть hashjoin вместо mergejoin ? Или там hash join выбирается когда одна таблица гораздо меньше другой?

(37) А может еще статистику не набрал?

(40) Точно!

Ладно, пока буду думать.

Я - программист 1С, разбираюсь с ВТ. Просто поверьте, у нас тут не всё так однозначно.

Вернусь вечером.

Если бы индексы увеличивали производительность всегда в соединениях, то 1С могла бы сама определять какие поля нужно индексировать в момент превращения своего запроса в ЭсКьюЭльный

(39) mergejoin  однозначно для полного соединение.
hash join может мало уступать merge-join даже на полном соединении. Поэтому наверное при выборе алгоритма этот метод и выбирают. 7500 это небольшой набор данных.

Загадка для любителей.

Добейтесь использования IndesSeek по индексированному полю в ВТ.

(45) Наложи отбор. Зачем ему делать IndexSeek, если ты соединяешь ВСЮ таблицу? Сделай условие, при котором возьмется лишь малая часть строк.

+(46) Но нюанс в том, что ВТ чаще всего уже собирается со всеми необходимыми отборами. Поэтому IndexSeek в ее случае - это либо ВТ была избыточна и используется с разными фильтрами потом несколько раз, либо была криво продумана.

(46) ВТ обычно уже отобрана, для этого она и используется в 90%

(46)
"Наложи отбор."
Стоп, Стоп, Стоп.

Этот отбор будет использовать Индекс, но потом, Соединение все равно будет перебирать полностью его результат.
Это немного не вписывается в задачу. Вернее, 1С не уточняет, что Индекс будет использоваться не для Условия во Соединению, а для Отбора.

Хреново представляю, как это выглядит в xml плане, но проверю позже.

Еще раз: пример некорректный. В данном случае вообще не нужны ВТ

(0) Все зависит от запроса использующего ВТ. Если есть соединение, и по логике вещей основной таблицей должна быть ВТ, то индекс не нужен.

(51) Приведи корректный пример.

Например номенклатура + остатки будет более лучший пример

(54) Тоже счаст подумал

Счаст затестим.

Остатки лучше брать задним числом, чтоб не просто по таблице итогов

(57) Нафига? Они у меня в ВТ пойдут, я этот пункт рассматривать не буду.

ВЫБРАТЬ
    ТоварыНаСкладахОстатки.Номенклатура КАК Номенклатура,
    ТоварыНаСкладахОстатки.КоличествоОстаток
ПОМЕСТИТЬ ВТ
ИЗ
    РегистрНакопления.ТоварыНаСкладах.Остатки КАК ТоварыНаСкладахОстатки

ИНДЕКСИРОВАТЬ ПО
    Номенклатура
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    СправочникНоменклатура.Наименование,
    ВТ.КоличествоОстаток
ИЗ
    Справочник.Номенклатура КАК СправочникНоменклатура
        ЛЕВОЕ СОЕДИНЕНИЕ ВТ КАК ВТ
        ПО (ВТ.Номенклатура = СправочникНоменклатура.Ссылка)



IndexScan по индексу с Наименованием спр. Номенклатура (ну это то и понятно) + Clustered Index Scan по ВТ.

hash join

сменим поле
СправочникНоменклатура.Наименование
на
СправочникНоменклатура.НаименованиеПолное

и получим

Clastered Index Scan по спр. Номенклатура + Clustered Index Scan по ВТ

MergeJoin

Такие дела.
Другой индекс в основной таблице - уже другой тип соединения (merge join).

А все же.
Ascent
Еще раз.

Как алгоритм ВООБЩЕ может использовать indexSeek хотя бы в merge join согласно вот этой теории?

wiki:%C0%EB%E3%EE%F0%E8%F2%EC_%F1%EE%E5%E4%E8%ED%E5%ED%E8%FF_%F1%EB%E8%FF%ED%E8%E5%EC_%F1%EE%F0%F2%E8%F0%EE%E2%E0%ED%ED%FB%F5_%F1%EF%E8%F1%EA%EE%E2

Только IndexScan по индексу только из за сортировки.

А без индекса?

Индекс сик может быть только в нестед лупс

Хотя нет, туплю.

В псевдокоде по моей ссылке, при indexseek вместо

Пока Таблица1.Колонка1 < Taблица2.Колонка2
         Таблица1.ПерейтиКСледующейЗаписи;

Должно быть

Таблица1.Найти()

(62) Воот!

(62) Nested looops у нас обычно во вложенных запросах, так?

(64) те ты хочешь заставить нестед лупс вместо хэш джойн?

(66) Нет. Согласно теории, merge-join вроде бы не использует индексы (хотя я указал, что может), hash-join точно не используется индексы (надо полным перебором построить хеш в обоих таблицах).

Вот что я хочу сказать.

А nested loops вполне себе кучеряво может использовать Индекс, но опять таки, Nested Loops возникает в 1С во влеженных запросах, а не В ИНДЕКСИРОВАННЫХ ВТ :-)

Nested loop is generally chosen for smaller tables and if it is possible to do Index seek on the inner table to ensure better performance.

Merge Join is considered to be more efficient for large tables with the keys columns sorted. It only need to read the keys once, and does not require lot of CPU cycles.  

Hash Join is also better suited for large tables. This requires less IO, but need more CPU and requires lot of memory.
http://tomyrhymond.wordpress.com/2011/10/01/nested-loop-hash-and-merge-joins/

Ладно, поехал я на экзамен по Эксперту, там поспорю :-)

(67) " merge-join вроде бы не использует индексы " Использует. Если верить этому: http://www.madeira.co.il/loop-hash-and-merge-join-types/ . Причем, это очень эффективно может быть.

(68) Во вложенных он возникает, потому что там идет отбор, который в случае с ВТ уже был сделан нами.

(67) merge-join как раз использует индексы, вернее сортировку. Посмотри на сортировку слиянием.
Там смысл таков
Тз1.Сортировать(СписокПолей);
    Тз2.Сортировать(СписокПолей);
    Тз2.ВыбратьСтроки();
    Тз1.ВыбратьСтроки();
    
    Фл1=Тз1.ПолучитьСтроку();
    Фл2=Тз2.ПолучитьСтроку();
    Пока (Фл1=1) И (Фл2=1) Цикл  
        ФлСравнения=Сравнение(ТзДляСравнений,тз1,Тз2,СписокПолей,СпзСписокПолей);
        Если ФлСравнения=-1 Тогда
//             Выводим Тз1.СравниваемыйЭлемент нен В Тз2 нет такого элемента

              Таб.ВывестиСекцию("ЕстьТолькоВТз1");      
            Фл1=Тз1.ПолучитьСтроку();
            // Получаем новую строку Тз1,

        ИначеЕсли  ФлСравнения=1 Тогда
            // Выводим Тз2.СравниваемыйЭлемент нен В Тз1 нет такого элемента

          Таб.ВывестиСекцию("ЕстьТолькоВТз2");
            Фл2=Тз2.ПолучитьСтроку();
        иначе
            //Строки равны

            //     ТзРазличий.НоваяСтрока();
Таб.ВывестиСекцию("ТзРавны");
            
            Фл1=Тз1.ПолучитьСтроку();
            Фл2=Тз2.ПолучитьСтроку();
        КонецЕсли;
        
        КонецЦикла;      
        
        //====== Проверяем остатки неравных строк

        Если (Фл1=0) и (Фл2=1) Тогда
                        
            Пока Фл2=1 Цикл
              
            //Оставшиеся строки По тз2
            Таб.ВывестиСекцию("ЕстьТолькоВТз2");
            Фл2=Тз2.ПолучитьСтроку();
        
            КонецЦикла;
            //Выводим ОстаткиТз2

        ИначеЕсли (Фл1=1) и (Фл2=0) Тогда
            //Выводим ОстаткиТз1    

            Пока фл1=1 Цикл
            //Оставшиеся строки По тз1
            Таб.ВывестиСекцию("ЕстьТолькоВТз1");
        
            Фл1=Тз1.ПолучитьСтроку();
            КонецЦикла;
        КонецЕсли;

Я тут. Завалил я экзамен. Чето я немного в ахере, ну да ладно.

(73) Я в курсе. Так все же. merge - join использует индексный поиск или все же только сортировку из индекса?

(74) индексный поиск использует только нестед лупс

(74) а мердж джойн использует 2 отсортированных (выбранных по индексу) набора данных

(75) (76) Вооот.

Теперь дальше идем.

Вопрос: при каком количестве присоединяемых данных (индексированных) есть переход от нестед лупс к хэш джойн (основная таблица без индекса считаем)

Что быстрее -
построить отсортировать колонку, построить дерево, выбрать ВНИМАНИЕ, из этого дерева сортированно данные.

или

отсортировать колонку

?

(3) а ты заметил, что они не используют слова "все" и "всегда"?

indexscan - это не простой обход списка. Это рекурсивный обход дерева!

(79) отсортировать + выбрать или просто отсортировать?

+(80) эта книжка, она во многом на кулинарную похожа - "солить по вкусу" и "варить до готовности" в ней довольно часто встречаются

(81) а разница то?

(82) Отсортировать и выбрать.

Это я для того, чтобы показать, что Выбрать из индекса - это не просто выбрать :-)

(84) Обойди мне это дерево по возрастанию. Начиная с корня
wiki:B-дерево#mediaviewer/Файл:B-tree-definition.png

(74) По уму только сортировку по индексу. Попробуй полное соединение

http://www.sql.ru/articles/mssql/2007/051102mergejoin.shtml

Для того, что бы задействовать слиянием "один ко многим", оптимизатор должен иметь возможность определить, что один из входных потоков состоит из уникальных строк. Как правило, это означает, что у такого входного потока существует уникальный индекс или в плане запроса присутствует явным образом оператор (например, сортировка при DISTINCT или группировка), который гарантирует, что строки на входе будут уникальны.

(88) (89) Это я все прочитал. Индексного поиска нет.
Ясно.

(90) У тебя фобия какая-то? Зачем он, если Merge тупо эффективнее?

(91) Тупо эффективнее чего?

(91) Он в детстве молился на бога индекс сик )))

(92) это самый эффективный способ джойна

(94) Прекрасно.
Я согласен с тем, что это самый эффективный способ джойна.
Я не понимаю, зачем для этого джойна нужно строить индекс, если его нет...

p.s. Ты уже обошел дерево индекса?

(95) а в чем проблема то? стека на хватит?

(96) Вернемся к этому вопросу завтра, а то у вас голова не варит :-)

Асцент, напряги мозг, он есть у тебя :-)

(97) не понимаю твоего непонимания )))

(98) Зачем нужно строить Индекс для mergejoin, если его нет.

Вот вытяжка моего непонимания.

(99) а как без индекса?

(100) TableScan по ВТ с сортировкой.

(101) так сортировка - это и есть тот же индекс практически

(102) Найн! Нихт!

Чтобы сделать IndexScan - нужно:
Отсортировать. Построить дерево. Обойти дерево рекурсивно.
Чтобы сделать TableScan - нужно:
Отсортировать и обойти результат линейно.

(0) v8: Как получить записи из первой таблицы которых нет во второй?
v8: Временные таблицы и индексы в запросах

(103) Дык наличие индекса уже подразумевает упорядоченность данных. Поэтому делают Мердж, т.к. все нужное уже есть.

(103) Б+ деревья не обходятся рекурсивно. Так как нижние страницы связаны http://rsdn.ru/article/alg/tlsd.xml

(106) Спасибо тебе, добрый человек.

(105) *facepalm

Как вы пользователей то понимаете, если 4 строк понять не можете.

(106) Нижние страницы все же связаны у "твоего" двухмерного словара поиска (TwoLevelSortedDictionary) или у B+ дерева?

Интересно, как при наличии связности страниц в пределах одного уровня будет производиться вставка новых значений и балансировка.

(109) Там есть пример и B+ дерева. Посмотри. Принцип тот же, просто добавляются новые уровни

wiki:B+_%E4%E5%F0%E5%E2%EE

(108) С утреца все ясно стало, что тебя смущает. Сейчас смотрю у себя


ВЫБРАТЬ
    Ссылка
ПОМЕСТИТЬ ВТ
ИЗ
    Справочник.Спр_1

ГДЕ
    Владелец В(&Список)
    
;

ВЫБРАТЬ
    Спр_2.Ссылка
ИЗ
    Справочник.Спр_2 КАК Спр_2
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВТ КАК ВТ
        ПО ВТ.Ссылка = Спр_2.Владелец


В плане по ВТ - TableScan, по справочнику IndexScan и в в соединении HashJoin.

Добавляю индексация и получаю для ВТ ClusterdIndexScan, но в соединении остается HashMatch. Бред...

(114) Ничего страшного в этом нет :-)
Измени Равенство на Сравнение и будет Merge :-)

(115) А вот тут я не понимаю. Зачем SQL вообще использует Hash  в этой ситуации? Он считает, что создать, хранить и обрабатывать таблицу хэшей экономнее, чем содержать вспомогательную таблицу для хранения прошлый строк при Merge?..

(0) Итог какой?
В каком случае ИНДЕКСИРОВАТЬ будет полезно?
Так чтобы это чувствовалось (ускорение запроса хотя бы в 1.5-2 раза).

(117) Когда фильтруешь по индексированным колонкам

(118) Можно пример запроса?

(117) Когда ВТ используешь больше одного раза.

(116) Если таблица небольшая, то проще запихнуть ключи в Хэштаблицу.
Вот для примера сравнение подсчета слов в тексте с применением разнных словарей
http://rsdn.ru/article/alg/tlsd.xml

Число слов в тексте=528124
Количество слов  20359

Заполнение SortedDictionary                    1.53828656994115
Заполнение QuickDictionary (через индексатор)  0.189289700227264
Заполнение Dictionary                          0.309536826607851
Заполнение TLSD (через индексатор)             0.860960541074354
Заполнение QuickDictionary (прямой доступ)     0.08363381379477
Заполнение TLSD (прямой доступ)                0.368364694395517
Заполнение Б+-дерева (прямой доступ)           0.461643030049909
Заполнение MySortedDictionary                  0.984015566224199

Там разница более чем в 4 раза.

Индексирование однозначно лучше хорошо когда нужно искать на больше или меньше. В том числе max, min

(0) Рекомендации в книгах предназначены для средних 1С-ников, которые в оптимизацию SQL не лезут и лезть не собираются. "В среднем" это рекомендации правильные. Потому что плюсы (у оптимизатора появляется больший выбор) сильно перевешивают минусы (индекс строится быстро на типичных объемах ВТ - тысячах и десятках тысяч записей). Даже если индекс не пригодился - ну и фиг с ним.

А ты, если уж влез в оптимизацию, должен усвоить, что теоретические рассуждения тут не стоят почти ничего. Профайлер в зубы и показывай цифры. Тут на вопрос "что быстрее, A или B" ответ всегда - "it depends".

P.S. Всю ветку не читал.

(0) А если чуть усложнить:
ВЫБРАТЬ
    Номенклатура.Ссылка КАК Ссылка,
    Номенклатура.Артикул КАК Артикул,
    Номенклатура.Код КАК Код
ПОМЕСТИТЬ Временная
ИЗ
    Справочник.Номенклатура КАК Номенклатура

ИНДЕКСИРОВАТЬ ПО
    Ссылка,
    Артикул,
    Код
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    Временная.Код,
    Номенклатура.Наименование
ИЗ
    Временная КАК Временная
        ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Номенклатура КАК Номенклатура
        ПО Временная.Ссылка = Номенклатура.Ссылка
            И Временная.Артикул = Номенклатура.Артикул