Привет, всем! В УПП - есть регистр сведений "Версии объектов", измерение "Объект" - составной тип содержит все справочники и все  документы. Необходимо выбрать версии по определенным типам объекта. Я написал следующий запрос..:

ВЫБРАТЬ
    ВерсииОбъектов.Объект,
    ВерсииОбъектов.НомерВерсии,
    ВерсииОбъектов.ВерсияОбъекта,
    ВерсииОбъектов.АвторВерсии,
    ВерсииОбъектов.ДатаВерсии
ИЗ
    РегистрСведений.ВерсииОбъектов КАК ВерсииОбъектов
ГДЕ
    (ВерсииОбъектов.Объект ССЫЛКА Документ.ВводНачальныхОстатковОС
            ИЛИ ВерсииОбъектов.Объект ССЫЛКА Документ.ИзменениеСпособовОтраженияРасходовПоАмортизацииОС
            ИЛИ ВерсииОбъектов.Объект ССЫЛКА Документ.КорректировкаЗаписейРегистров
            ИЛИ ВерсииОбъектов.Объект ССЫЛКА Документ.ПринятиеКУчетуОС)

Как сделать более оптимально?
Недавно прочитал статью про составной тип данных - понял, что при неумелом пользовании в запросах.. можно дорого заплатить по времени)

(33) откуда там будет соединение-то?

(32) Ты план запроса смотри

+36 а лучше покажи

(33) не будет никаких соединений без залезания "внутрь" составного типа за реквизитом

(35) Хотя вообще, да, из регистра же данные тащим

StmtText                                                                          
Clustered Index Seek(OBJECT:([database].[dbo].[_InfoRg24333].[_InfoR24333_ByDims_RN] AS [T1]), SEEK:([T1].[_Fld24334_TYPE]=0x08 AND [T1].[_Fld24334_RTRef]=0x00000104 OR [T1].[_Fld24334_TYPE]=0x08 AND [T1].[_Fld24334_RTRef]=0x00000147 OR [T1].[_Fld24334_TYPE]=0x08 AND [T1].[_Fld24334_RTRef]=0x0000015F OR [T1].[_Fld24334_TYPE]=0x08 AND [T1].[_Fld24334_RTRef]=0x000001C8) ORDERED FORWARD)

а где вариант с ОБЪЕДИНИТЬ ВСЕ?

(41) Тогда все, в (0) запрос уже оптимален

(41) Ты понимаешь, что индекс здесь используется по признаку Ссылка, а не по признаку Документ.чтото ?

(44) Чего?

(44) Я не понял твоего каммента.

(45) MrStomak просто не в курсе, как хранятся данные в базе 1с и какие там индексы

(47) В курсе
(46) Из твоего поста я понял (32), что используется предикат по полю T1._Fld24334_TYPE в физическом операторе. Это был бы частичный поиск по индексу, так как нужно использование двух полей. Проверил сам - в предикатах поиска присутствует также второе поле.

(48)
Ты очень сложно выражаешь свои мысли. Давай я проще:

1С наложила условие на Класс метаданных (справочник/документ/ПВХ/БизнесПроцесс) и на тип класса метаданных (Документ.ВводОстатков/Документ.РТУ).
И это прекрасно.

Не наложи она условия на Класс метаданных  (_Fld24334_TYPE]=0x08)

индекс бы пошел лесом.

Понапридумывали тут.. (ворчит)

http://www.sql.ru/articles/mssql/2007/012302seekpredicates.shtml

Для следующих ниже примеров, мы можем использовать индекс для удовлетворения условий предиката для столбца "a", но не для столбца "b". В этих случаях потребуется остаточный предикат:

a > 100 and b > 100 a like 'abc%' and b = 2

"потребуется остаточный предикат"
Объясните мне, как это по русски.

indexseek+indexscan?

как это выглядит в профайлере?

Вот так правильно условия:

a > 100 and b > 100

a like 'abc%' and b = 2

(51) В профайлере это выглядит как разделение в тексте плана запроса SEEK и WHERE, но всё это будет index seek

(49) Если преобразовать текст запроса из (0) так:
ВЫБРАТЬ
    ВерсииОбъектов.Объект,
    ВерсииОбъектов.НомерВерсии,
    ВерсииОбъектов.ВерсияОбъекта,
    ВерсииОбъектов.АвторВерсии,
    ВерсииОбъектов.ДатаВерсии
ИЗ
    РегистрСведений.ВерсииОбъектов КАК ВерсииОбъектов
ГДЕ
    (ВерсииОбъектов.Объект ССЫЛКА Документ.ВводНачальныхОстатковОС
            ИЛИ ВерсииОбъектов.Объект ССЫЛКА Документ.ИзменениеСпособовОтраженияРасходовПоАмортизацииОС
            ИЛИ ВерсииОбъектов.Объект ССЫЛКА Документ.КорректировкаЗаписейРегистров
            ИЛИ ВерсииОбъектов.Объект ССЫЛКА Документ.ПринятиеКУчетуОС
            или версииобъектов.объект = значение(Документ.ПринятиеКУчетуОС.ПустаяСсылка))

,то тоже будет Index seek, тоже будут в условии запроса все поля, но при этом будет использоваться только индекс по первому полю TYPE. Я из твоего поста подумал, что именно это и произошло.

(53) Счаст пытаюсь представить себе физический смысл "a > 100 and b > 100" для b дерева и не понимаю проблемы.

(55) Я не понял поста (52) Это к чему?

(56) Я слитно написал их, эти 2 варианта условий в (50), исправился.

(55) Как ты это сделаешь, кроме как сначала выбрав все записи где а>100, а потом, уже из них, где b>100?

(58) Индексное дерево для 2-х полей строится одно?

(58) Или для каждого поля - отдельное дерево. Для полей, в составном индексе.

(60) Как может быть несколько деревьев в индексе? Одно дерево.

Ядро СУБД Cach? использует B+-деревья для хранения данных...
После имени глобала в круглых скобках через запятую
указывается произвольное количество индексов. Компилятор осуществляет
преобразование всего множества индексов в ключ B+-дерева...

Вот.

Тоесть, при выполнении условия "a > 100 and b > 100", это условие должно преобразоваться в условие вида
"key>100"

И потом выполнить типовой поиск по B+ дереву.

Хотя нет.

Ключом B+ дерева тут будет скорее всего Структура с элементами
[a,b]

Или хэш.

Блин.

Нет. Нельзя хэш. Нам нужны исходные данные.

Например, для получения данных через индекс.

Хэш используется для соединений, в индексе мы последовательно сверяем куски известного ключа со значениями для каждой "развилки".

(68) Ты, скорее всего, меня не понял.

(68)

wiki:B-%E4%E5%F0%E5%E2%EE#mediaviewer/Файл:B-tree-definition.png

Что находиться в КЛЮЧЕ корневого узла k1, индексного дерева для полей а, b таблицы, в которой поле a имеет значения от 0 до 100, поле b имеет значение от 100 до 200.

Я вот думаю - там структура со значениями
50,100

Вот ссылка

http://commons.wikimedia.org/wiki/File:B-tree-definition.png#mediaviewer/Файл:B-tree-definition.png

(70) Почему 50,100? Там должна быть конкатенация значений всех ключей.

(70) Точнее, всех полей.

(72) как потом вытаскивать данные, ну, допустим при indexscan?

(72) Как сконкатенировать date и nvarchar?

(74) первые столько-то байт - первое поле, вторые столько-то байт - второе поле

(76) Тупо побайтовый набор? Это и есть Структура.

(77) я думал, у тебя 50,100 означало разные узлы, где значение только а, а не структуру со значениями а и б.

Ну да, так будет узел выглядеть, 50,100

(79) Отлично!

добравшись до узла , где a=100, мы знаем, что всё остальное точно удовлетворяет предикату a>100 и отбираем это. Если мы продолжаем поиск, и находим удовлетворение условию b>100, то это совсем не означает, что все остальные строки удовлетворяют этому условию! Потому что там дальше может быть а=110, б=2, следующая запись а=110 б = 112, потом опять а=111 б = 1. Дальше как ни крути, нужно выполнять скан всех строк индекса.

(81) Стоп. А разве дерево не отсортировано?

Соединяй правым соединение с таблицами этих документов, будет отбор на уровне SQL, отработает быстро.

(82) Отсортировано. Вот тебе порядок - 110 2, 110 112, 111, 1.
Это всё в порядке сортировки побайтовой конкатенации значений полей.

В B-дереве чтобы выполнять поиск по всем полям у нас необходимое условие, чтобы предикаты на все поля, кроме последнего, были на эквивалентность.

(84) таймаут! Пошел думать.

(84) Почему то мне кажется, что сортировка будет не по конкатенации байтов, а по значения полей.

а по значения полей.-> а по значениям полей.

(83) *грустно смотрит*

В корне у нас должны быть серединки диапазонов.

(88) какая разница?

Все. Это для меня слишком сложно. Мне нужно на бумажке начертить дерево и карандашиком поискать по нему.

(89) Пробовал, что бы критиковать? Мб не так причину скорости выполнения написал, но это работает ;)

(90) Ключ один, какие серединки?

(93) тут уже профайлером выяснили, что идет индекс сик по всем условиям.

(94) Ключ один физически, состоит из 2-х частей логически. Я же привел пример со структурой
[50,100]

(92) Не рассматривай а и б как разные ключи. Это один ключ, и он отсортирован.

50 - серединка диапазона [0..100] для поля a
100 - серединка диапазона [0..200] для поля b

(97) Тоесть, в корневом узле, значение ключа не [50,100] ?

(98) нету отдельного диапазона для поля б

(99) Наверху дерева первое значение, то есть 0,100

дальше узлы нормализованно распределяются

(100) При построении индекса - строится побайтовая конкатенация, сортируется, выбирается середина, ее значение записывается в структуру ключа корневого узла?

при этом вторая часть ключа нам бесполезна

(101) Посмотри на схемку http://commons.wikimedia.org/wiki/File:B-tree-definition.png#mediaviewer/Файл:B-tree-definition.png

Там в корневом узле - значение середины диапазона.
И алгоритм поиска - именно по тому, больше или меньше искомое значение значению ключа. В зависимости от этого - идем по нужным потомкам - ветвям.

(105) ты прав, там середина будет.

(106) Фух... Продолжим...
(103) - Это все так?

Ну и середина эта определяется как среденее значение сконкатенированного ключа.

Да

(108) Среднее значение или значение середины диапазона?

(1068) Запись за номером N/2 в отсортированном массиве, где N- число разных ключей.

Даже не разных, есть варианты неуникального индекса наверное.

(111) т.е. Значение середины диапазона. Ок.

(111) Вот теперь все ясно.

Вот теперь понятен смысл последующего indexscan по b>100 после indexseek по a>100

т.е. в корневом узле значение 50,100 может получиться при равномерном рампределении, т.е. одному ключу а соответствует уникальный ключ б.

Я думал, дерево отсортировано по значениям полей a и b, а не по их побайтовой конкатенации.

(116) Или там у тебя б=100 это начало диапазона.. Такое уже будет от везения зависеть.

(117) Ну так ты спросил вроде бы для этого - одно или несколько деревьев? Нельзя отсортировать один ключ двумя способами.

(119) Точнее, в один момент времени он будет отсортирован только одним образом.

(118) Это очень редкий шанс для больших таблиц.

(119) Я вообще не знал про физику хранения составных индексов.

мне кажется автор темы сейчас очень грустно на нее смотрит) ну и да - закладка.

Для (70) правка

поле b имеет значение от 100 до 200. ->

поле b имеет значение от 0 до 200.

(0) самый лучший вариант оптимизации это не выгребать в запросе поле версия объекта.

(125) Он и не выгребает.

1С не тупее паровоза.

(126) а это тогда кто ВерсииОбъектов.ВерсияОбъекта

(128) Это будет потом, скорее всего, при Хранилище.Получить().

(0) вторая проблема в том, что если это выводится в тз или еще как-то (не через СКД), то система будет делать запрос вида:
SELECT
T1._IDRRef,
T1._Number,
T1._Date_Time
FROM _Document128 T1 WITH(NOLOCK)
WHERE T1._IDRRef = P1

для получения представления для каждой ссылки.

(129) это идет сразу, если через запрос, то сервер 1с все это выгребает и преобразовывает с свои объекты.

(131) Да, ты прав, не заметил это поле в профайлере.

Но как бы, скорее всего, это то и нужно автору.

(133) если идет обработка в цикле версий, то скорее всего это сервисная обработка и вопрос скорости выполнения не стоял. Скорее всего это какой-то отчет или еще что-то.